User based licensing for applications

ABSTRACT

A method, system, and computer-readable storage media for providing user based licensing of an application are provided herein. The method includes receiving user log-in information from a computing device at a licensing service in response to an input by a user and providing a license for an application to the computing device, wherein the license includes device specific information associated with the user. The method also includes activating the application on the computing device using the device specific information.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation of U.S. patent applicationSer. No. 14/493,226, filed Sep. 22, 2014, which is a continuation ofU.S. patent application Ser. No. 14/459,055, filed Aug. 13, 2014 whichis a continuation of U.S. patent application Ser. No. 13/680,120, filedNov. 16, 2012, now U.S. Pat. No. 8,832,851 issued Sep. 9, 2014, andclaims benefit of the filing date of the U.S. Provisional PatentApplication Ser. No. 61/591,703 filed Jan. 27, 2012, the disclosure ofwhich is incorporated herein by this reference as though fully set forthherein.

BACKGROUND

Licenses, or entitlements, are generally used to control the manner inwhich client computing devices may access particular applications, suchas, for example, word processing applications, spreadsheet applications,and presentation applications. Typically, each type of client computingdevice has a distinct licensing service, wherein the type of a clientcomputing device may include a particular operating system (OS) of theclient computing device or a brand of the client computing device, forexample. However, the use of such distinct licensing services for eachtype of client computing device results in several limitations. Forexample, high costs may be associated with building and sustaining aseparate licensing service for each type of client computing device. Inaddition, it may be desirable to provide bundling offers, which includelicenses for one or more applications that may be used on multiple typesof client computing devices. However, the use of separate licensingservices may preclude such bundling offers, since bundling relies onintegration between many different types of devices or systems. Further,it may be difficult for a marketplace service to integrate with eachseparate licensing service for the selling of licenses, and consistentproof of license ownership may be difficult to attain. For example, onelicensing service may use product keys, while another licensing servicemay use tokens.

SUMMARY

The following presents a simplified summary of the innovation in orderto provide a basic understanding of some aspects described herein. Thissummary is not an extensive overview of the claimed subject matter. Itis intended to neither identify key nor critical elements of the claimedsubject matter nor delineate the scope of the subject innovation. Itssole purpose is to present some concepts of the claimed subject matterin a simplified form as a prelude to the more detailed description thatis presented later.

An embodiment provides a method for providing user based licensing of anapplication. The method includes receiving user log-in information froma computing device at a licensing service in response to an input by auser, providing a license for an application to the computing device,wherein the license includes device specific information associated withthe user, and activating the application on the computing device usingthe device specific information.

Another embodiment provides a system for providing user based licensingof an application. The system includes a licensing service that isconfigured to receive user log-in information from a computing device inresponse to an input by a user, provide a license for an application tothe computing device, wherein the license includes device specificinformation associated with the user, and activate the application onthe computing device using the device specific information.

Another embodiment provides one or more computer-readable storage mediaincluding a number of instructions that, when executed by a processor,cause the processor to receive user log-in information from a computingdevice and provide a license for an application to the computing device,wherein the license includes device specific information associated witha user. The instructions also cause the processor to activate theapplication on the computing device using the device specificinformation, periodically determine a state of the license, and adjustconditions of the license according to the state of the license.

This Summary is provided to introduce a selection of concepts in asimplified form; these concepts are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a networking environment that may be usedto implement the licensing service described herein;

FIG. 2 is a block diagram of a computing environment that may be used toimplement the licensing service described herein;

FIGS. 3A, 3B, and 3C show a schematic of a licensing system that may beused to manage licenses for applications;

FIG. 4 is a process flow diagram of a method for purchasing a licensefor an application through a marketplace service;

FIG. 5 is a process flow diagram of a method for the initial activationof a license for an application through a marketplace service;

FIG. 6 is a process flow diagram of a method for the reactivation of alicense for an application;

FIG. 7 is a block diagram showing a number of entitlements, or licenses,that have been licensed to a user for a number different machines;

FIG. 8 is a process flow diagram of a method for converting anentitlement to another offer or updating the offer relating to theentitlement;

FIG. 9 is a process flow diagram of a method for verifying an identityof a user and an identity of an entitlement for which keylessauthorization is to be provisioned;

FIG. 10 is a process flow diagram of a method for provisioning a keylessauthorization as appropriate;

FIG. 11A is a process flow diagram of a method for retrieving anexisting subscription (or TBL) key;

FIG. 11B is a process flow diagram of a method for obtaining a newsubscription key;

FIG. 12A is a process flow diagram of a method for retrieving anexisting product key;

FIG. 12B is a process flow diagram of a method for obtaining a newproduct key;

FIG. 13 is a process flow diagram of a method for retrieving machinesfrom an entitlement;

FIG. 14 is a process flow diagram of a method for deprovisioning aspecific machine from an entitlement;

FIG. 15A is a process flow diagram of a method for the initial purchaseof an entitlement by a user;

FIG. 15B is a process flow diagram of a method for updating anentitlement;

FIG. 16 is a process flow diagram of a method for provisioning a user inOLS, or converting a user from one entitlement to another;

FIG. 17 is a process flow diagram of a method for determining whether toupdate an entitlement according to a ForcedUpdate process;

FIG. 18A is a process flow diagram of a method for the initial licensingof an application for a device;

FIG. 18B is a process flow diagram of a method for periodically checkingthe state of a license;

FIG. 19 is a process flow diagram of a method for initially licensing adevice;

FIG. 20 is a process flow diagram of a method for the determination by apartner of whether a user is to be granted access to its services;

FIG. 21 is a schematic of an exemplary configuration of a masterdatacenter and multiple replica datacenters;

FIG. 22 is a schematic showing a first step for executing a planneddowntime;

FIG. 23 is a schematic showing a second step for executing a planneddowntime;

FIG. 24 is a process flow diagram of a method for application licensing;

FIG. 25 is a process flow diagram of a method for licensing anapplication using sync providers;

FIG. 26 is a process flow diagram of a method for licensing anapplication using multiple forms of licensing;

FIG. 27 is a process flow diagram of a method for licensing anapplication for devices; and

FIG. 28 is a process flow diagram of a method for providing user basedlicensing of an application.

DETAILED DESCRIPTION

Embodiments disclosed herein set forth methods and systems forapplication licensing according to various criteria and techniques. Asused herein, the term “application” may refer to an application,program, or service implemented within a computing environment.Applications that may be utilized in accordance with the licensingservice described herein include, but are not limited to, MICROSOFTWORD, MICROSOFT EXCEL, MICROSOFT POWERPOINT, MICROSOFT VISIO, orMICROSOFT SHAREPOINT, all of which are available from MicrosoftCorporation of Redmond, Wash. Applications may be provided to acomputing device by a marketplace service, or any of a number of thirdparty services, via a network. Various different types of licenses, orentitlements, for such applications can be obtained through a variety ofdifferent methods.

The licensing service described herein solves the problems discussedabove with respect to the use of separate licensing services byproviding an extensible and consistent way to license new clientcomputing devices. In addition, the licensing service allows newpartners, i.e., commerce partners, to easily sell applications byisolating the licensing process from the purchasing process. Inaddition, the licensing service enables offers which span acrossdifferent clients, or client devices. The licensing service also allowsa user of different clients to prove they are provisioned to use anapplication via a single set of credentials. Furthermore, the licensingservice allows for the inclusion of a synchronizing license periodacross devices and services, even when a device goes offline. This mayallow the experience on all devices and services to remain consistentwhen a subscription lapses.

The licensing service may be referred to herein as the “Office LicensingService,” or “OLS,” since it may be used to license MICROSOFT OFFICE,i.e., “Office,” applications available from Microsoft Corporation ofRedmond, Wash., such as the ones listed above. However, it is to beunderstood that the licensing service may also be used to license anyother suitable types of applications available from any number ofproviders.

In various embodiments, the OLS provides the ability to use multiplelicensing methods through a consistent, expandable, and well-defined setof protocols. Such licensing methods may include, for example, productkey based licensing, online user based licensing, device basedlicensing, and token based licensing, among others.

In some embodiments, the OLS is configured to periodically check auser's license state. This may allow for a balance between the abilityto use the product offline and the ability to obtain the latestlicensing information, e.g., whether a license has been deprovisioned.The user's license state may be referred to as the “subscriptionheartbeat.” The subscription heartbeat may be used to determine whethera license for an application is to be disabled, thereby deactivating thecorresponding application.

The OLS may provide for the synchronization of the user's license stateacross multiple devices and services. In some embodiments, the OLSenables devices running Office, e.g. PC, Mac, Mobile, or Slates, amongothers, and Office Services, e.g., roaming settings, to have aconsistent license state. Thus, when a user's subscription lapses,access to clients and services may be severed at the same time. Inaddition, by presetting the amount of offline license time that isallowed for a particular device, the license state can be synchronizedeven if the user goes offline.

Further, the OLS may provide for the tolerance of offline clients, aswell as the detection of fraud. For example, the OLS may include logicthat determines when a new client is requesting a license versus when anexisting client is requesting a renewed license. The OLS may alsoinclude logic that determines when a user is performing fraudulentactivities, such as requesting excessive numbers of new licenses, whilestill allowing a user to add and remove devices and maintain a certainnumber of active devices.

In various embodiments, the OLS provides for licensing of devices. Forexample, the OLS may provide for licensing of MOX devices, wherein theterm “MOX” generally refers to all Windows 8 Slate devices. The OLS mayprovide such licensing using credentials and an OLS license. An OLSlicense is a new form of license that is different from traditionalauthorization granted via a product key. An OLS license may includeconfigurable license check periods configured from the server outsidethe traditional system, e.g., the traditional Office Software ProtectionPlatform (OSPP) system.

In various embodiments, the OLS may provide licensing for services.Specifically, the OLS may provide a scalable way to provide licensingfor services using a poll model, wherein a service would query the OLSas appropriate. The OLS may cache provisioning/license information for acertain amount of time on the service or client themselves in order tomake the system scalable. In addition, a push model may be used toprovide licensing for services.

The OLS may allow for disaster resilience. For example, a close to zeroday recovery point and close to zero minute recovery time may beachieved via geographically distributed servers that are kept in syncusing custom geographical replication logic. This may be accomplished byseparating information that is to be kept in sync at all times frominformation that can be in sync to a certain degree, and thensynchronizing the information via a pool of sync providers. In addition,locking mechanisms may be used to avoid overwrites.

Further, the OLS may provide for user based licensing. Licensinginformation for using the rich client application may be sent from theserver, and may be based on the user's log-in information. The licensinginformation may be retained on the server instead of the client, and thelicensing information may be roamed along with the user on the server.This may be used in a number of scenarios, such as for roamingapplications or for initial acquisition before key based licensing isused.

As a preliminary matter, some of the figures describe concepts in thecontext of one or more structural components, variously referred to asfunctionality, modules, features, elements, etc. The various componentsshown in the figures can be implemented in any manner, for example, bysoftware, hardware (e.g., discreet logic components, etc.), firmware,and so on, or any combination of these implementations. In oneembodiment, the various components may reflect the use of correspondingcomponents in an actual implementation. In other embodiments, any singlecomponent illustrated in the figures may be implemented by a number ofactual components. The depiction of any two or more separate componentsin the figures may reflect different functions performed by a singleactual component. FIG. 1, discussed below, provides details regardingone system that may be used to implement the functions shown in thefigures.

Other figures describe the concepts in flowchart form. In this form,certain operations are described as constituting distinct blocksperformed in a certain order. Such implementations are exemplary andnon-limiting. Certain blocks described herein can be grouped togetherand performed in a single operation, certain blocks can be broken apartinto plural component blocks, and certain blocks can be performed in anorder that differs from that which is illustrated herein, including aparallel manner of performing the blocks. The blocks shown in theflowcharts can be implemented by software, hardware, firmware, manualprocessing, and the like, or any combination of these implementations.As used herein, hardware may include computer systems, discreet logiccomponents, such as application specific integrated circuits (ASICs),and the like, as well as any combinations thereof.

As to terminology, the phrase “configured to” encompasses any way thatany kind of functionality can be constructed to perform an identifiedoperation. The functionality can be configured to perform an operationusing, for instance, software, hardware, firmware and the like, or anycombinations thereof.

The term “logic” encompasses any functionality for performing a task.For instance, each operation illustrated in the flowcharts correspondsto logic for performing that operation. An operation can be performedusing, for instance, software, hardware, firmware, etc., or anycombinations thereof.

As used herein, terms “component,” “system,” “client” and the like areintended to refer to a computer-related entity, either hardware,software (e.g., in execution), and/or firmware, or a combinationthereof. For example, a component can be a process running on aprocessor, an object, an executable, a program, a function, a library, asubroutine, and/or a computer or a combination of software and hardware.

By way of illustration, both an application running on a server and theserver can be a component. One or more components can reside within aprocess and a component can be localized on one computer and/ordistributed between two or more computers. The term “processor” isgenerally understood to refer to a hardware component, such as aprocessing unit of a computer system.

Furthermore, the claimed subject matter may be implemented as a method,apparatus, or article of manufacture using standard programming and/orengineering techniques to produce software, firmware, hardware, or anycombination thereof to control a computer to implement the disclosedsubject matter. The term “article of manufacture” as used herein isintended to encompass a computer program accessible from any tangiblecomputer-readable storage device, or media.

Computer-readable storage media include storage devices (e.g., harddisk, floppy disk, and magnetic strips, among others), optical disks(e.g., compact disk (CD), and digital versatile disk (DVD), amongothers), smart cards, and flash memory devices (e.g., card, stick, andkey drive, among others). In contrast, computer-readable media (i.e.,not storage media) may additionally include communication media such astransmission media for communication signals and the like.

Moreover, the word “exemplary” is used herein to mean serving as anexample, instance, or illustration. Any aspect or design describedherein as “exemplary” is not necessarily to be construed as preferred oradvantageous over other aspects or designs.

Computing Environment

In order to provide context for implementing various aspects of theclaimed subject matter, FIGS. 1-2 and the following discussion areintended to provide a brief, general description of a computingenvironment in which the various aspects of the subject innovation maybe implemented. For example, a method and system for licensing anapplication can be implemented in such a computing environment. Whilethe claimed subject matter has been described above in the generalcontext of computer-executable instructions of a computer program thatruns on a local computer or remote computer, those of skill in the artwill recognize that the subject innovation also may be implemented incombination with other program modules. Generally, program modulesinclude routines, programs, components, data structures, etc., thatperform particular tasks or implement particular abstract data types.

Moreover, those of skill in the art will appreciate that the subjectinnovation may be practiced with other computer system configurations,including single-processor or multi-processor computer systems,minicomputers, mainframe computers, as well as personal computers,hand-held computing devices, microprocessor-based or programmableconsumer electronics, and the like, each of which may operativelycommunicate with one or more associated devices. The illustrated aspectsof the claimed subject matter may also be practiced in distributedcomputing environments wherein certain tasks are performed by remoteprocessing devices that are linked through a communications network.However, some, if not all, aspects of the subject innovation may bepracticed on stand-alone computers. In a distributed computingenvironment, program modules may be located in local or remote memorystorage devices.

FIG. 1 is a block diagram of a networking environment 100 that may beused to implement the licensing service described herein. The networkingenvironment 100 includes one or more client(s) 102. The client(s) 102can be hardware and/or software (e.g., threads, processes, or computingdevices). The networking environment 100 also includes one or moreserver(s) 104. The server(s) 104 can be hardware and/or software (e.g.,threads, processes, or computing devices). The servers 104 can housethreads to perform search operations by employing the subjectinnovation, for example.

One possible communication between a client 102 and a server 104 can bein the form of a data packet adapted to be transmitted between two ormore computer processes. The networking environment 100 includes acommunication framework 108 that can be employed to facilitatecommunications between the client(s) 102 and the server(s) 104. Theclient(s) 102 are operably connected to one or more client data store(s)110 that can be employed to store information local to the client(s)102. The client data store(s) 110 may be stored in the client(s) 102, ormay be located remotely, such as in a cloud server. Similarly, theserver(s) 104 are operably connected to one or more server data store(s)106 that can be employed to store information local to the servers 104.

FIG. 2 is a block diagram of a computing environment that may be used toimplement the licensing service described herein. The computingenvironment 200 includes a computer 202. The computer 202 includes aprocessing unit 204, a system memory 206, and a system bus 208. Thesystem bus 208 couples system components including, but not limited to,the system memory 206 to the processing unit 204. The processing unit204 can be any of various available processors. Dual microprocessors andother multiprocessor architectures also can be employed as theprocessing unit 204.

The system bus 208 can be any of several types of bus structures,including the memory bus or memory controller, a peripheral bus orexternal bus, or a local bus using any variety of available busarchitectures known to those of ordinary skill in the art. The systemmemory 206 is computer-readable storage media that includes volatilememory 210 and non-volatile memory 212. The basic input/output system(BIOS), containing the basic routines to transfer information betweenelements within the computer 202, such as during start-up, is stored innon-volatile memory 212. By way of illustration, and not limitation,non-volatile memory 212 can include read-only memory (ROM), programmableROM (PROM), electrically-programmable ROM (EPROM), electrically-erasableprogrammable ROM (EEPROM), or flash memory.

Volatile memory 210 includes random access memory (RAM), which acts asexternal cache memory. By way of illustration and not limitation, RAM isavailable in many forms, such as static RAM (SRAM), dynamic RAM (DRAM),synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhancedSDRAM (ESDRAM), SynchLink™ DRAM (SLDRAM), Rambus® direct RAM (RDRAM),direct Rambus® dynamic RAM (DRDRAM), and Rambus® dynamic RAM (RDRAM).

The computer 202 also includes other computer-readable storage media,such as removable/non-removable, volatile/non-volatile computer storagemedia. FIG. 2 shows, for example, a disk storage 214. Disk storage 214includes, but is not limited to, devices like a magnetic disk drive,floppy disk drive, tape drive, Jaz drive, Zip drive, LS-100 drive, flashmemory card, or memory stick.

In addition, disk storage 214 can include storage media separately or incombination with other storage media including, but not limited to, anoptical disk drive such as a compact disk ROM device (CD-ROM), CDrecordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or adigital versatile disk ROM drive (DVD-ROM). To facilitate connection ofthe disk storage 214 to the system bus 208, a removable or non-removableinterface is typically used, such as interface 216.

It is to be appreciated that FIG. 2 describes software that acts as anintermediary between users and the basic computer resources described inthe computing environment 200. Such software includes an operatingsystem 218. The operating system 218, which can be stored on diskstorage 214, acts to control and allocate resources of the computer 202.

System applications 220 take advantage of the management of resources bythe operating system 218 through program modules 222 and program data224 stored either in system memory 206 or on disk storage 214. It is tobe appreciated that the claimed subject matter can be implemented withvarious operating systems or combinations of operating systems.

A user enters commands or information into the computer 202 throughinput devices 226. Input devices 226 include, but are not limited to, apointing device (such as a mouse, trackball, stylus, or the like), akeyboard, a microphone, a gesture or touch input device, a voice inputdevice, a joystick, a satellite dish, a scanner, a TV tuner card, adigital camera, a digital video camera, a web camera, or the like. Theinput devices 226 connect to the processing unit 204 through the systembus 208 via interface port(s) 228. Interface port(s) 228 include, forexample, a serial port, a parallel port, a game port, and a universalserial bus (USB). Output device(s) 230 may also use the same types ofports as input device(s) 226. Thus, for example, a USB port may be usedto provide input to the computer 202 and to output information from thecomputer 202 to an output device 230.

An output adapter 232 is provided to illustrate that there are someoutput devices 230 like monitors, speakers, and printers, among otheroutput devices 230, which are accessible via the output adapters 232.The output adapters 232 include, by way of illustration and notlimitation, video and sound cards that provide a means of connectionbetween the output device 230 and the system bus 208. It can be notedthat other devices and/or systems of devices provide both input andoutput capabilities, such as remote computer(s) 234.

The computer 202 can be a server hosting an event forecasting system ina networking environment, such as the networking environment 100, usinglogical connections to one or more remote computers, such as remotecomputer(s) 234. The remote computer(s) 234 may be client systemsconfigured with web browsers, PC applications, mobile phoneapplications, and the like. The remote computer(s) 234 can be a personalcomputer, a server, a router, a network PC, a workstation, amicroprocessor based appliance, a mobile phone, a peer device or othercommon network node and the like, and typically includes many or all ofthe elements described relative to the computer 202. For purposes ofbrevity, the remote computer(s) 234 is illustrated with a memory storagedevice 236. Remote computer(s) 234 is logically connected to thecomputer 202 through a network interface 238 and then physicallyconnected via a communication connection 240.

Network interface 238 encompasses wire and/or wireless communicationnetworks such as local-area networks (LAN) and wide-area networks (WAN).LAN technologies include Fiber Distributed Data Interface (FDDI), CopperDistributed Data Interface (CDDI), Ethernet, Token Ring and the like.WAN technologies include, but are not limited to, point-to-point links,circuit switching networks like Integrated Services Digital Networks(ISDN) and variations thereon, packet switching networks, and DigitalSubscriber Lines (DSL).

Communication connection(s) 240 refers to the hardware/software employedto connect the network interface 238 to the system bus 208. Whilecommunication connection 240 is shown for illustrative clarity insidecomputer 202, it can also be external to the computer 202. Thehardware/software for connection to the network interface 238 mayinclude, for example, internal and external technologies such as mobilephone switches, modems including regular telephone grade modems, cablemodems and DSL modems, ISDN adapters, and Ethernet cards.

Licensing System

FIGS. 3A, 3B, and 3C show a schematic of a licensing system 300 that maybe used to manage licenses for applications. The licensing system 300 isdescribed with respect to an Office Licensing Service (OLS) 302 that isused to manage licenses for Office applications, or applications thatare available through Office. However, it is to be understood that thelicensing system 300 may also be used to manage any other suitable typesof applications or services.

The licensing system 300 may include a number of sync providers 304A-D.The sync providers 304A-D are pluggable components that allow forextensibility of the licensing system 300 without modification of theOLS 302. The sync providers 304A-D may allow a number of commercepartners to interact with the OLS 302. For example, as shown in FIG. 3A,a Microsoft Online (MSOnline) sync provider 304A may allow forinteraction between the OLS 302 and a MSOnline partner 306A. An OfficeMarketplace Experience (OMEX) sync provider 304B may allow forinteraction between the OLS 302 and an OMEX partner 306B. A Point ofSale Activation (POSA) sync provider 304C may allow for interactionbetween the OLS 302 and a POSA partner 306C.

In addition, a client sync provider 304D may allow for interactionbetween the OLS 302 and a client computing device 308. The clientcomputing device 308 may be any suitable type of computing device, suchas a desktop computer or laptop computer, that can be licensed to user aparticular application or service via the licensing system 300 using theOLS 302. Furthermore, any number of new commerce partners may also beintegrated into the licensing system 300 using any number of additionalsync providers.

As shown in FIG. 3A, each sync provider 304A, 304B, 304C, and 304D mayinclude one or more components for performing the actions requested bythe respective partner 306A, 306B, 306C, and 308D. In addition, eachsync provider 304A, 304B, 304C, and 304D may interact with one or moreprovisioning application programming interfaces (APIs) 310 within theOLS 302, as indicated via arrows 312A, 312B, 312C, and 312D,respectively. The provisioning APIs 310 are used by the OLS 302 toperform provisioning actions. Sources calling the provisioning APIs 310,such as the sync providers 304A-D, are generally assumed to be trustedsources.

OLS APIs

The OLS 302 may include a number of OLS APIs 314, which are used toretrieve information from the OLS 302, as well as to send and receiveinformation from the client computing device 308. The OLS APIs 314 maybe called by an Office Licensing Client (OLC) 316 of the clientcomputing device 308, as indicated by arrows 318A and 318B. The OLS APIs314 may also be called by any services or websites 320A and 320B thatdesire to send or obtain machine or licensing information from the OLS302, as indicated by arrows 322A, 322B, and 322C. The OLS APIs 314 mayperform actions such as checking the provisioning status of a productkey or a user, or retrieving a product key, for example.

In some embodiments, there are two sets of OLS APIs 314, including apublic version that is accessible through the internet and is called bythe OLC and a private version that is accessible only by certain trustedpartners and is called by those partners. The main difference betweenthe public version and the private version of the OLS APIs 314 is thatthe private version may accept a passport unique ID (PUID) as anidentity rather than user credentials, and the private version may beimplemented as a different end point using different servers than thepublic version.

The OLC 316 of the client computing device 308 is a client-sidecomponent that handles client-side licensing functions such ascommunicating with the OLS 304, activating a license via OSPP 324,interfacing with the UI, and providing authorization for Office 326 torun on the client computing device 308. The OLC 316 may also sendinformation to the POSA sync provider 304C and the client sync provider304D, as indicated by arrows 328A and 328B, respectively. For example,the OLC 316 may push data relating to the license of the clientcomputing device 308 into the client sync provider 304D.

In various embodiments, the OLC 316 also communicates with an identityplatform 330. The identity platform 330 may include information relatingto the identity of the user, such as the user's Office Marketplace ID,i.e., Live ID. Such information may be used to activate Office 326 onthe client computing device 308.

The OLC 316 may recognize whether the user, or client, activated Office326 using a Live ID or a BPOS ID. This may enable the use of contextspecific user interfaces. For example, the Live ID UI may be differentfrom the BPOS UI. In addition, the OLC 316 may be able to determinewhich UI to display to the user according to the download location orthe CD used to install Office 326.

The OLS 302 may include a product key cache service 332 and a productkey cache 334. The product key cache 334 may be a regularly replenishedcache of product keys that are used by the OLS 302. The product keycache service 332 may be configured to retrieve product keys from aproduct key storage database 336, as indicated by arrow 338.

The OLS 302 may also include a deprovisioning service 340. Thedeprovisioning service 340 may be an asynchronous service that checksfor deprovisioned product keys in OLS via communication with anActivation Verification System (AVS) 342, as indicated by arrow 344. Thedeprovisioning service 340 may also periodically deactivate licensesthat are associated with deprovisioned product keys via the AVS 342.

The licensing system 300 may also include a fraud detection system 346.The fraud detection system may include a fraud detection service 348 anda fraud detection database 350. The fraud detection service 348 may syncrelevant data into the fraud detection database 350 from a licensingstore 352 of the OLS 302 on a regular basis. The fraud detection service348 may obtain the data from the licensing store 352 via a data accesslayer 354 of the OLS 302, as indicated by arrow 356. The fraud detectionservice 348 may then analyze the data separately from the OLS 302, thusreducing the load on the OLS 302. In various embodiments, implementingthe fraud detection system 346 separately from the OLS 302 also allowsfor upgrading of the components of the fraud detection system 346without altering the OLS 302.

Use of Licensing Service for Office

This section provides several exemplary embodiments of the use of thelicensing service (or OLS) described herein for Office or, morespecifically, Office 2013 (also known as Office 15). In Office 2013, theOLS may support a variety of licensing models, such as BusinessProductivity Online Suite (BPOS) subscriptions, wherein the term “BPOS”is used interchangeably with Microsoft Online and Microsoft 365, andconsumer subscriptions. The OLS may also support classic perpetuallicensing, trial licensing, and keyless, i.e., credential based,licensing, as well as conversions between the various models.Furthermore, the OLS may support these different models in the contextof different delivery methods, such as Original Equipment Manufacturer(OEM) preload, CD, and Electronic Software Distribution (ESD).

The various licensing models to be supported by the OLS in Office 2013are key business priorities for Office 2013. A single system that canhandle all of these various models may reduce the overhead and thecomplexity of Office 2013.

BPOS Scenarios

BPOS scenarios are scenarios that are focused on business. Suchscenarios typically involve an administrator (admin), and the resultinglicenses are typically associated with an organization instead of an enduser. Therefore, the admin may be able to take a license away from oneuser and assign it to another user within the organization. Furthermore,BPOS scenarios may include subscriptions only.

The following is an explanation of several exemplary embodiments ofsubscription purchasing and provisioning for BPOS scenarios. Accordingto such embodiments, the owner of a company purchases BPOS and an Officesubscription with eight user licenses as part of BPOS for his employees.The information technology (IT) admin for the company creates an accountincluding BPOS credentials for each of the eight employees. The IT adminthen provisions a user license for Office for each of the employees.

User with a Single Machine

An employee receives an email from the IT admin informing her that shecan now use Office 2013. The email has a link to Office.com, whichprovides information about products and services that are available forher use. The employee clicks on the email link, is asked to sign in withher BPOS credentials, and sees a link to launch Office 2013. Theemployee clicks on the link, and Office 2013 starts momentarily. WhenOffice 2013 launches, the employee is asked to verify her credentials toactivate Office 2013.

User with Multiple Machines

When the employee visits Office.com, she learns that the subscriptionpermits installation of Office 2013 on up to two machines. Thus, theemployee signs in to Office.com from a second machine and uses the sameprocedure to install and launch Office on the second machine.

Although the employee knows that she is only entitled to use Office ontwo machines, she decides to see what happens if she tries to installand run it on a third machine. The employee follows the same procedure,and Office launches. This time, however, the employee is informed byOffice that she has already used her license on two other machines. Theemployee is presented with a list of the machines on which she hasinstalled Office, and is prompted to remove her license from one of theother machines to continue. Instead of selecting a machine to removefrom the list, she decides to cancel. The employee may still be able touse the Office installation on the third machine for a certain number ofdays, because the subscription license may allow for a grace period. Ifthe employee had chosen to remove her license from one of the existingtwo machines, the license on that machine would have been removed, andshe would have been able to activate her license on the third machine.

Deprovisioning User

A few months later, the employee takes a temporary leave. The ownerdecides to hire a temporary contract worker to fill in while theemployee is on leave. Before the contact worker's first day of work, thecompany's IT admin deactivate the employee's BPOS account, creates anaccount for the contract worker, and provisions the contract worker forOffice.

On the contract worker's first day of work, he is given the employee'scomputer and the account that was created for him Upon starting Office,the contract worker is informed that the current Office license on hismachine has lapsed, and that he may provide another account to continueusing Office. The contract worker enters his account information and isable to use Office normally. If the contract worker had not provided hisaccount, there may still have been a grace period during which he couldhave continued using Office.

Subscription Renewal

After nearly a year has passed, the owner of the company receives arenewal notification email. The owner decides to extend the subscriptionfor another year. The owner visits Office.com to renew the subscription.Meanwhile, the employees may experience uninterrupted use of Office.

Large Enterprise Scenarios

Large enterprise scenarios are essentially the same as BPOS scenarios.However, large enterprise scenarios may include a federation setup thatallows a user to activate Office with his domain credentials, possiblyeven using silent authorization if they are currently signed into theirdomain.

The following is an explanation of several exemplary embodiments ofsubscription purchasing and provisioning for large enterprise scenarios.According to such embodiments, a supply manager for the company travelsfrequently for work. He is sometimes without his computer and borrowswhat he can from his suppliers. He was one of the employees that the ITadmin of company had provisioned for Office.

User Roams Office Applications to an Unknown Machine

On the supply manager's trip to another company, he forgets his laptop.However, he desires access to a spreadsheet he was working on.Fortunately, he remembers that the company's Office subscription allowshim access to Office from anywhere at any time. The supply managerborrows a laptop from an IT manager at the other company and logs intoOffice.com. Through Office.com, the supply manager is able to launchExcel for temporary use, and is able to retrieve the spreadsheet. At theend of the day, the supply manager returns the laptop to the othercompany.

Upon receiving the laptop, the IT manager of the other company issurprised to find no traces of the supply manager's spreadsheet orOffice on the laptop. This is due to the fact that the number of timesOffice can be opened per day is monitored and limited to prevent fraud.

The supply manager may be prompted for his credentials when launchingExcel, or they may be remembered by Office.com. Office.com may knowwhether or not the supply manager has Office on the machine he iscurrently using. The BPOS website may have choices for the supplymanager to provision the particular machine, or to use Office on themachine temporarily. In some cases, Office may remain on the machine.However, when the IT manager of the other company boots Office, he isprompted for credentials before being allowed to use Office.

Subscription Upgrade from Office 2010 to Office 2013

The company has been using a BPOS Office 2010 (or Office 14)Subscription for a few years, and the owner is very happy with it. A fewdays ago, the owner received an email alerting him and the IT admin thatOffice 2013 is available for upgrade as part of the company'ssubscription. The owner is also informed that his current installationsof Office 2010 will continue to work, but only for another year.

The IT admin goes to the BPOS administrator website and upgrades thecompany's employees to Office 2013. Each employee then receives an emailwith instructions to download Office 2013.

The supply manager receives the email and clicks on a link to Office.comfrom the email. He is asked to sign in with his BPOS credentials, andsees a link to launch Office 15. He clicks on the link, and Officestarts momentarily. When Office launches, he is asked to verify hiscredentials in order to activate Office. The company's accountant, onthe other hand, ignores the email and continues to use Office 2010. Inone year, the accountant's installation of Office 2010 stops working,while the supply manager's installation of Office 2013 continues towork.

Office Market Place (OMEX) Scenarios

OMEX scenarios are focused on end users. According to such scenarios,the end user purchases Office via Office.com or via the backstage ofOffice 2013. Such scenarios can include both perpetual and subscriptionlicenses. The licensing user interface (UI) may be able to determinewhether a user is associated with a BPOS scenario or an OMEX scenario,and may display the appropriate UI.

User Upgrades from Legacy Version of Office Through Office.com

The following is an example of a scenario in which the user upgradesfrom a legacy version, i.e., an existing version, of Office throughOffice.com. A user has been using Office 2010 Home and Student on hiscomputer and would now like to purchase the latest version. The usergoes to Office.com and is offered a selection. The user decides to buy asubscription. After creating a Live ID and paying for the subscription,the user launches Office 2013. A warning appears on the screen to alertthe user that he has an older copy of Office on his machine. After theuser confirms that he wishes to continue, Office 2010 is safelyuninstalled, and the new version launches. The user is prompted for thecredentials with which he bought the subscription. The user enters hiscredentials and is able to use Office normally.

In some embodiments, Office 2013 presents the user with a choice ofwhether to download/install Office 2013 or launch Office 2013.Credentials may be remembered and automatically passed from the Internetto Office 2013 such that no prompt for credentials is imposed on theuser. For example, the actual Product key may be inserted into the filename if the site of the download is secured. However, it may bedesirable to force the user to sign-in to verify their credentials evenif the credentials can be passed. In some cases, it may be assumed thatusers buying from Office.com have a Live ID. The product key may bebacked up on the user's legacy copy of Office.

User Purchases Office Subscription License Through Office.com

This scenario is the same as the scenario in which the user upgradesfrom a legacy version of Office through Office.com, except there is nowarning regarding a legacy version of Office because there is no legacyversion on the machine. In various embodiments, the user is not askedfor his credentials after the initial activation of the particularmachine. Rather, subsequent activations are done through MachineKey.

User Purchases Office Perpetual License Through Office.com

This scenario is the same as the scenario in which the user upgradesfrom a legacy version of Office through Office.com, except there is nowarning regarding a legacy version of Office because there is no legacyversion on the machine. The user may or may not be able to see theproduct key, depending on the specific instance. The user may be allowedto activate the perpetual license using his log-in information. Transferscenarios may be handled in a number of different ways, depending on thespecific instance. For example, if the user wants to sell his Office toanother user, he may have to give his credentials to the new user, orgifting may be supported.

User Updates Office Subscription on First Computer from Second ComputerThrough Office.com when User Owns Office Subscription on First Computer

According to this scenario, a user purchases Office 2013 Home andStudent subscription and installs it on his desktop and on his laptop.The user decides to upgrades to Office 2013 Professional. From thedesktop, the user goes to Office.com and upgrades the subscription. InOffice.com, the computers currently on his Office 2013 Home and Studentsubscriptions are listed, and the user is informed that those computerswill be automatically updated to Office 2013 Professional if thecomputers have internet access when the user launches Office on thosecomputers. The user is also given a link to upgrade the desktop now. Theuser clicks on the link immediately and provides his credentials. Officethen upgrades to Office 2013 Professional on the desktop.

A few days later, the user launches Word on his laptop. When Wordlaunches, the user is informed that a licensing change has taken place,and the user is given a choice to upgrade now to Office 2013Professional, to upgrade later, or to remove this machine from thesubscription. The user decides to upgrade later. A day later, the useragain launches Word and is given the same choices. The user decides toupgrade at that point in time.

In various embodiments, the user may be able to update the desktop viaOffice.com if he is using Office.com on the desktop. In some cases, theuser may also be allowed to choose an “upgrade later” choice. In othercases, the upgrade may be forced immediately. If “upgrade later” isallowed, the user may be allowed to select that choice a specific numberof times before the upgrade is forced. The user may be prompted to entercredentials on update now or remove actions.

User Updates Office Subscription on First Computer from Second ComputerThrough Office.com when User does not Own Office Subscription on FirstComputer

According to this scenario, a user purchases Office 2013 Home andStudent Subscription and installs it on his desktop. The user buys aused laptop from a friend. His friend's Office 2013 Professionalsubscription is running on the used laptop. The user is able to useOffice normally on the used laptop. The user's friend remembers that heforgot to remove his Office 2013 Professional subscription from thelaptop, so he goes to Office.com and removes the laptop from hissubscription.

Upon starting Office the next time, the user is informed that thecurrent Office license on his machine has been removed, and that he mayprovide another account to continue using Office. The user may thenenter his credentials in order to use the version of Office that issupported by his subscription.

User Updates Office License from Subscription License to PerpetualLicense on First Computer from Second Computer Using Office.com whenUser Owns Office Subscription on First Computer

This scenario is the same as the scenario in which the user updates theOffice subscription he uses on the first computer from the secondcomputer through Office.com when the user owns the subscription on thefirst computer. However, instead of upgrading to another subscriptionlicense, the user simply upgrades to a perpetual license.

User Updates Office License from Subscription License to PerpetualLicense on First Computer from Second Computer Through Office.com whenUser does not Own Subscription on First Computer

This scenario is the same as the scenario in which the user updates theOffice subscription he uses on the first computer from the secondcomputer through Office.com when the user does not own the subscriptionon the first computer. However, instead of upgrading to anothersubscription, the user upgrades to a perpetual license.

User Changes Office License from Perpetual License to SubscriptionLicense on First Computer from Second Computer Through Office.com whenUser Owns Perpetual License on First Computer

The user has Office Home and Student on a first computer. However, theuser discovers that he has a desire for a larger selection of Officeproducts. The user logs on to Office.com from a second computer topurchase Office Professional Subscription. At the end of the purchase,the user is given a link to download Office Professional and directionson how to update a currently installed version of Office.

The user logs onto Office.com again on the first computer and clicks onthe download link. The copy of Office on the first computer is updatedto Office.com Professional. If the user had not revisited Office.com, hecould have performed the update via going to the backstage on hiscurrently installed Office Home and Student. For example, the user mayclick on a button for updating the license or checking for updates.

The user later cancels his subscription. The Professional subscriptionon the first computer eventually lapses and reverts back to Office Homeand Student.

Licensed User Different from Current User

A small business owner has three employees. He would like each of hisemployees to use Office. After reviewing the subscription offers onOffice.com, the owner realizes that each subscription includes anentitlement to use Office on two different machines. However, the ownerrealizes he can only have one subscription at a time. Thus, he asks oneof the employees to also purchase a subscription, which he thenseparately expenses. The owner and one of the employees download Officeon their respective computers and activate it using the owner'scredentials. The two other employees download Office on their respectivecomputer and activate it using the employee's credentials. Topersonalize Office, the employees are still able to log in with theirown ID and use it normally.

In some embodiments, it may be assumed that each user can only have oneOffice subscription. However, in some cases, a user may have asubscription for Office Home and Student, as well as a subscription forOffice Professional. Also, a user may have multiple versions of the samesubscription, or multiple perpetual licenses.

User Converts from Subscription License to BPOS License

A small business owner has three employees. The owner and one of theemployees both have Office Professional subscriptions that allowinstallation of Office on up to two machines. The other two employeesare each using one of the subscriptions to install Office on theirmachines.

The owner has recently hired five new employees. Upon readinginformation online, he decides that a BPOS subscription will better fithis desires. The owner goes to Office.com and converts his subscriptionto a BPOS subscription, purchasing nine licenses (enough for everyone atthe company).

The owner creates and gives BPOS accounts to each of his employees andprovisions each for Office. When each employee launches Office, he isinformed that the license currently on his machine is no longer validand that he may provide another account in order to continue usingOffice. Thus, each employee may enter their BPOS ID, and then use Officenormally. Further, in some embodiments, a grace period is provided if anemployee does not provide another account immediately.

User Converts from Perpetual License to BPOS License

A small business owner has ten employees. The owner had purchasedperpetual licenses of Office Home and Business for each employee'smachine. However, upon reading information online, the owner decidesthat a BPOS subscription with Office Professional Plus will better fithis desires. The owner goes to Office.com and purchases a BPOSsubscription with eleven licenses (enough for everyone at his company).The owner creates and gives BPOS accounts to each of his employees andprovisions each for Office.

Each employee is given directions from the owner to go to their BPOShome page to download the Office subscription. Alternately, they arealso given directions on how to change their license from the backstage.If the employees take no actions on their current machines, theirmachines will continue to run whatever perpetual license is currently ontheir machine, even if they sign in with their BPOS ID.

User Cancels Subscription Through Backstage

A user has a basic Office subscription package but desires a largerselection of Office products. The user goes into the backstage andselects “My Account”. The user selects “Manage My Subscription” andupgrades his bundle to one which contains the products he desires. Whenhe no longer desires the additional products, the user goes to “MyAccount” under the backstage and cancels his subscription. The user'scopy of Office returns to a reduced functionality mode, or whateverlicense he had before he upgraded his bundle.

User Cancels Subscription Through Office.com

A user has a basic Office subscription package but desires a largerselection of Office products. The user logs on to Office.com to managehis current subscription. The user upgrades his bundle to one whichcontains the products he desires. When the user no longer desires theadded products, he logs in to Office.com and cancels his subscription.His copy of Office returns to a reduced functionality mode that wassupported by his previous license.

User Purchases Both Perpetual License and Subscription License

A user has Office Starter on his laptop. The user signs into OfficeMarketplace with his Live ID, and buys Office via the backstage usinghis laptop. Office Starter is upgraded to the Subscription package.

Later, the user returns to Office Marketplace via a web browser in orderto buy a perpetual license. The user does not have to re-enter hispayment details. Instead, Office Marketplace remembers his credentials.After the user confirms the purchase, he downloads and launches Officeon the laptop.

A few months after he purchases Office, the user gets a virus on hislaptop, and his applications are to be reinstalled. The user logs ontothe Office Marketplace in order to re-download his copy of Office andhis license. This may be accomplished using the same product key.

Subscription Renewal

If the user has an Office subscription, he may automatically renew thesubscription. The user may experience uninterrupted use of Office.

Subscription Lapses

A user has an Office Subscription. However, he does not care for theservice and decides to let it lapse when it expires. The billing systemsends the user numerous emails, which he ignores. Throughout this time,the user continues to use Office. He is notified through Office at somepoint that his subscription has expired, and that he may manage hissubscription from the backstage. He ignores these warnings, andeventually, Office stops functioning on his computer.

Subscription Upgrade from Office 2013 to Next Version of Office

A user has an Office Subscription for Office 2013 and currently hasOffice 2013 installed on his computer. A few years have passed, and thenext version of Office has been released. The next time the userlaunches any Office application, he is notified that he can upgrade tothe new version of Office. The user is also notified that he can do soat any time from the backstage. The user decides to upgrade now. The newversion of Office is installed on the user's computer.

In some embodiments, a number of components may notify users that a newversion of Office is out, such as OMEX or Office Licensing Client (OLC),or both. In some cases, the amount of time the user has left to upgradeto the next version may be tracked. At some point, an upgrade may beforced, and the old version may become unusable. Keys may come fromcorrect tax locations. The same logic may be used as for BPOS offers.

Retail/OEM/CD Scenarios

These scenarios are focused on traditional retail channels. A commontheme in these scenarios is that the user starts with a product key. Forexample, a product key is often includes in the box when the userpurchases Office.

User Purchases Office from Retail Store

A user goes to a retail store and purchases a box copy of Office Homeand Student. Inside the box is a CD as well as a product key. The userinstalls Office from the CD. As part of the installation process, theuser is prompted to enter his product key. The user is also prompted tosign into Office, and after doing so, he is given an opportunity toassociate his license with his Live ID. After a few months, the userfinds a virus on his computer. The user reformats the computer andreinstalls Office. Unfortunately, the user lost the Product Key.However, the user is able to activate Office using only his Live ID. TheOLS may return the product key that is associated with this Live ID.

User with Multiple Machines

A user has four computers at his house. The user had purchased a copy ofOffice from a retail store and was able to successfully activate Officeon the first computer with the product key. Since he associated thelicense with his Live ID when setting up his first computer, the userwas also able to activate Office on the second and third computers usinghis Live ID. However, upon trying to activate the fourth computer, theuser receives an error message informing him that his license onlysupports three computers.

User Associates Office License with Live ID

In general, if the user desires to associate his product key with hisLive ID, he may enter the full 5×5 product key into Office Marketplaceonline. Via Office Marketplace, the OLS may then associate the productkey with the user's Live ID.

The user may view the Office licenses that are associated with his LiveID online through Office.com, or through the backstage. In addition, theuser may be able to disassociate a product key from his Live ID throughOffice.com, or through the backstage. When the user attempts to use hisLive ID for activation again, he is unable to do so. However, computersthat have already been activated with his Live ID will function asnormal.

Trial Scenarios

These scenarios are directed to trial licenses and are essentially thesame as the non-trial subscription scenarios. However, the licenseperiod is much shorter for trial scenarios.

User Initiates Trial License Through Office.com

A user has been using Office Starter. The user decides to give Office atry and, after providing his Live ID, downloads a trial license fromOffice.com. Upon launching Office on his machine, the user is promptedto enter his Live ID. Once the user enters his Live ID, he is able tostart using Office.

User Initiates Trial License Using Product Key

A user has obtained a trial copy of Office. The trial copy of Officeincludes a product key that is associated with a trial license. The userinstalls Office and uses the product key to activate Office.

Trial License Lapses

A user has been using Office Starter and now desires to try out Office.After providing his Live ID, the user downloads a trial license fromOffice.com. As time passes, the user is notified from the OLC that histrial will expire soon. The user decides to let his trial license lapse.When his trial license expires, Office reverts back to Office Starter.

User Converts from Trial License to Subscription License

Dan has been using a trial of Office he downloaded from Office.com. Astime passes, he is notified from the Office client that his trial willexpire soon. Dan had a good experience using Office 15 and decides toconvert to a full subscription via Office.com (or the backstage). Hiscopy of Office automatically upgrades to a full subscription with nointerruption in service.

If he activated trial via product key and never provided an ID, he mighthave to provide his ID to convert to full subscription.

Methods for Purchasing, Activating, or Reactivating License

FIG. 4 is a process flow diagram of a method 400 for purchasing alicense for an application through a marketplace service. In variousembodiments, the marketplace service is the Office MarketplaceExperience (OMEX). Further, in some embodiments, the method 400 isimplemented via the licensing system 300 discussed above with respect toFIGS. 3A, 3B, and 3C.

The method 400 begins at block 402, at which the user initiates thepurchase of a license. The user may initiate the purchase through OfficeStarter, Office Trial, the backstage of Office, or Office.com, forexample. The user selects a store keeping unit (SKU) relating to thedesired license at block 404. At block 406, the user log-ins to theOffice Marketplace, e.g., OMEX, using his Live ID.

At block 408, it is determined whether the user is busing a subscriptionSKU. If the user is not buying a subscription SKU, the user may selectthe payment instrument at block 410 and complete the payment at block412. The OLS may then be notified of the license update via the OMEXsync provider at block 414.

If the user is buying a subscription SKU, the subscription SKU may beset up at block 416. The user may then select the payment instrument atblock 418 and complete the payment at block 420. At block 422, thesubscription details may be recorded. For example, the SKU, autorenewalinformation, and/or billing interval information may be recorded. TheOLS may then be notified of the license update via the OMEX syncprovider at block 414.

FIG. 5 is a process flow diagram of a method 500 for the initialactivation of a license for an application through a marketplaceservice. In various embodiments, the marketplace service is OMEX. Theinitial activation of the license may take place on one client device,e.g., one computer, and may not include upsetting. In some embodiments,the method 500 is implemented via the licensing system 300 discussedabove with respect to FIGS. 3A, 3B, and 3C.

The method 500 begins at block 502, at which OMEX passes parameters,such as the authorization ticket, to the bootstrapper. The userinitiates the download from Office.com at block 504. Bits are retrievedfrom the content delivery network (CDN) at block 506, and a splashscreen is displayed at block 508 while the bits are being retrieved.

At block 510, the OLC requests a generic license from the licensingstore. This allows temporary use of Office while the license is beingactivated. Office loads at block 512, and the OLC requests the licensefrom the OLS using the authorization ticket at block 514. At block 516,the OLS returns a secured authorization (or keyless authorization) and aproduct key (in the case of a non-roaming application scenario).

At block 518, the OLC determines if the product key and OSPP areavailable. If the product key and OSPP are available, an OSPP license isobtained with the product key at block 520. A passport unique ID (PUID)and username of the user are saved on the local machine at block 522.

If the product key and OSPP are not available, use of Office may beenabled via keyless authorization. The OLC may then periodicallydetermine if the product key and OSPP are available at block 518, andmay take the appropriate action if the product key and the OSPP becomeavailable.

FIG. 6 is a process flow diagram of a method 600 for the reactivation ofa license for an application. Such a method of reactivation may includeupsetting. In some embodiments, the method 600 is implemented via thelicensing system 300 discussed above with respect to FIGS. 3A, 3B, and3C.

The method 600 begins at block 602, at which Office is loaded or ascheduled license check occurs. At block 604, it is determined if thelicense for Office is a subscription license or a trial license. If thelicense is not a subscription license or a trial license, it isdetermined to be a perpetual license. In this case, the method 600continues at block 606, at which the user uses Office normally. In somecases, Office may stop functioning if the license has expired or beenterminated for some reason.

If the license is a subscription license or a trial license, the OLCsends license information to the OLS at block 608, and the OLS returnslicense updates to the OLC at block 610. At block 612, it is determinedwhether the license has been updated. If the license has been updated,OLC updates Office with the new license. In some cases, the user may bepresented with an option of whether the user wishes to implement the newlicense now or later via a UI. In addition, if the new license involvesa change in the version of Office, the new version may be downloaded.Alternatively, if the license has not been updated, the method 600 mayreturn to block 606. In this case, the license may be expired and, thus,Office may stop functioning.

Office Licensing Service (OLS)

This section describes the functioning of the OLS of the licensingsystem described herein, such as the OLS 302 of the licensing system 300described above with respect to FIGS. 3A, 3B, and 3C. The OLS serves asthe central hub of the licensing system. The OLS obtains provisioningdata, e.g., what the user bought, from various sources, such as BPOS orOMEX. The OLS also obtains product keys, provides keyless authorization,and manages user-to-machine relationships, e.g., how many machines theuser has activated.

The OLS may allow the licensing system to handle licenses for variousdifferent types of operating systems or devices. This may result in areduction of the overhead for licensing applications. The OLS may alsoprovide agility and flexibility with changes in the business model andprovide a centralized view of user-to-license information.

In various embodiments, OMEX provides an interface for the OLC to managemachines for a user identity. OMEX also provides an interface forwebsites, e.g., the OMEX management website, to manage machines for auser identity. OMEX may maintain a database of IDs, licenses relating tothe IDs, and the machines for which the licenses have been used. Inaddition, OMEX may provide the ability to obtain license keys from a keystore. Further, OMEX may provide an interface by which the OLC mayauthorize Office usage, either via product key distribution (for casesin which OSPP is available) or via a straightforward authorization basedmodel (for cases in which OSPP is not available, i.e., keylessauthorization scenarios).

The OLS provides at least three broad classes of services, includinguser licensing provisioning, product key and roaming authorizationretrieval, and machine management capabilities, as explained furtherbelow. With regard to user licensing provisioning, the OLS can store andretrieve information relating to the type of Office license to which theuser is entitled based on information provided by partners such as BPOSand OMEX. For example, the OLS can store and retrieve informationrelating to whether the user is currently subscribed to Office Home andBusiness, or whether he has bought perpetual Office Professional.

With regard to product key and roaming authorization retrieval, the OLShas the ability to retrieve the correct product key from a keystorebased on the Office license to which the user is entitled. Thiscapability is seamless to the user and the partner. In other words, theproduct key is retrieved on demand when the user is trying to activate amachine, and activation is done automatically by the OLC withoutexposing the actual product key to the user. However, the OLS does notinclude the ability for partners to arbitrarily retrieve a product key.Furthermore, the OLS also has the ability to retrieve roamingauthorization, i.e., keyless authorization, which enables the user touse Office in roaming application scenarios without a product key.

In some embodiments, the OLS provides machine management capabilitiesfor subscription licenses only. In addition to simply retrieving theproduct key, the OLS may also manage the number of machines which havebeen activated, and provide a way for a user to rotate the machines thatare included in his subscription. For example, if the subscription theuser bought entitles him to use Office on three machines, the OLS maydeprovision one of the first three machines if a fourth machine isprovisioned.

The database of the OLS may be organized by users, who may have one ormore entitlements and zero or more machines under each entitlement. Eachentitlement is associated with one and only one offer. For perpetualentitlements with perpetual offers, a single perpetual key may beassociated with each entitlement.

FIG. 7 is a block diagram showing a number of entitlements, or licenses,702A-E that have been licensed to a user 704 for a number differentmachines 706A-F. Each entitlement 702A-E may include an offer 708A-Drelating to either a perpetual entitlement or a subscriptionentitlement, or both, as discussed further below.

In various embodiments, the OLS only manages machines, e.g., machines706A, 706B, 706C, 706D, and 706F, that are provisioned using asubscription entitlement, e.g., entitlements 702A, 702B, and 702E.Therefore, users with perpetual entitlements, e.g., entitlements 702Cand 702D, will not have any machines associated with the entitlements,unless the machine, e.g., machine 706E, was previously converted from asubscription entitlement.

In various embodiments, an offer represents a type of usage right thatis available for purchase, for instance, through Microsoft Online orOMEX. Offers are not user specific, and are populated when the licensingsystem is brought online and updated. Additions and updates to offersmay be incorporated as part of deployment. Each offer may be associatedwith an offer ID, which is a unique ID that identifies the offer. Inaddition, each offer may be associated with a specific type of offer.For example, the offer may be a product key only offer, i.e., an offerrelating to a perpetual or trial license, or a machine management offer,i.e., an offer relating to a subscription license.

According to embodiments described herein, a license or entitlement is aspecific set of usage rights. A user may have one or more entitlements.The entitlements are populated by the sync providers duringprovisioning. Each entitlement has a unique entitlement ID, which may bedetermined in part by the provisioning partner.

A variety of information relating to each entitlement may be recordedalong with the entitlement. For example, the entitlement ID, the partnerentitlement ID, the corresponding partner, the user ID, the offer ID,and the state of the entitlement may be recorded. In addition, values ofvarious parameters relating to the entitlement may be recorded. Forexample, information relating to whether the entitlement enables roamingapplication scenarios, i.e., RoamingType, information relating to theuser's billing country, i.e., BillingCountryISO, and informationrelating to the language of the entitlement may be recorded. Inaddition, information relating to the maximum number of provisioned orpending conversion machines allowed on the entitlement, i.e.,ActiveMachineMax, information relating to the number of provisioned orpending conversion machines currently on the entitlement, i.e.,ActiveMachineCount, and a variety of other information may be recorded.Parameters relating to the token for the entitlements may also berecorded. Such parameters include SecureToken, TokenUseMax,TokenUseCount, TokenExpiryLength, and TokenExpiry, among others.

A machine may be a specific installation of Office using a specificsubscription entitlement. There may be zero or more machines under anentitlement. A new machine is created every time a new subscription (orTBL) product key is issued from an entitlement.

Each machine may be associated with a MachineKey, which may be used toidentify the machine. The value of the MachineKey may be derived fromthe product key which was issued for the machine. The status of themachine, such as whether the machine is provisioned, pending conversion,converted, or previsioned, may be recorded. In addition, various otherparameters relating to the machine may be recorded, including theentitlement ID, offer ID, key status, and information relating to themachine itself.

According to embodiments described herein, a product key, i.e.,ProductKey, is issued for each entitlement. There may be only oneenabled ProductKey under each entitlement, and only perpetualentitlements may have an enabled ProductKey. A ProductKey may be createdthe first time a product key is requested from a perpetual entitlement.As long as the entitlement has not been converted, the same perpetualkey is used on all subsequent key requests. Information relating to thestatus of the product key, i.e., KeyStatus, may be recorded. The statusof the product key may be enabled, pending disablement, or disabled.Information relating to the number of times the product key was issued,i.e., KeyslssuedCount, and information relating to the last date thatthe KeyStatus was updated, i.e., KeyStatusLastUpdate, may also berecorded along with the product key.

In various embodiments, the provisioning APIs are a set of internal APIsused for provisioning. The provisioning APIs are called by the syncproviders only. Each sync provider API may call one or more of theprovisioning APIs. The provisioning APIs may be designed to appear asatomic operations to the rest of the licensing system. Note that asingle provisioning action may take multiple provisioning API calls. Forexample, for a OMEX sync provider's ProvisionUser( ) API, both AddUser() and CreateEntitlement( ) calls are used. If AddUser( ) succeeds butCreateEntitlementForUser( ) fails, then the user may not have anentitlement, and the user will not be granted unauthorized access toOffice. Some examples of APIs within the licensing system include theAddUserQAPI, which adds a user to the OLS, the CreateEntitlement( ),which creates an entitlement for the user, and the ConvertEntitlement( )API, which converts an Entitlement to another offer or updates theparameter ActiveMachineMax. The ConvertEntitlement( ) API functions thesame regardless of whether the conversion is from a subscription licenseto another subscription license, or from a subscription license to aperpetual license, for example. In addition, unless explicitlyspecified, fraud counters and limits may not be reset during conversion.

FIG. 8 is a process flow diagram of a method 800 for converting anentitlement to another offer or updating the offer relating to theentitlement. The updating of the offer may include, for example,updating the ActiveMachineMax. The method begins at block 802, at whichthe ConvertEntitlement( ) API is called. It may be determined whetherthe entitlement is deprovisioned at block 804. If the entitlement isdeprovisioned, the method 800 ends at block 806. If the entitlement isnot deprovisioned, the method 800 continues to block 808, at which it isdetermined whether the existing offer is the same as the new offer.

If the existing offer is not the same as the new offer, it is determinedwhether there are existing provisioned machines for the entitlement atblock 810. If there are existing provisioned machines, all existingprovisioned machines are updated to status=pending conversion at block812. The method 800 then proceeds to block 814, at which the entitlementis updated to the new offer. If it is determined that there are noexisting provisioned machines at block 810, the method 800 automaticallyproceeds to block 814.

At block 816, it is determined whether the existingActiveMachineMax=MaxMachines. Further, if it is determined at block 808that the existing offer is the same as the new offer, the method 800 mayautomatically proceed to block 816.

If the existing ActiveMachineMax MaxMachines at block 816, theActiveMachineMax may be updated to MaxMachines at block 818. It may thenbe determined at block 820 whether the ActiveMachineCount is greaterthan the ActiveMachineMax. If the ActiveMachineCount is greater than theActiveMachineMax, the event is logged at block 822 before the method 800proceeds to block 824. Otherwise, the method 800 proceeds to block 824from block 820. Further, if the existing ActiveMachineMax=MaxMachines atblock 816, the method 800 automatically proceeds to block 824.

At block 824, it is determined whether there is an existing enabledPerpetualKey. If there is not an existing enabled PerpetualKey, themethod 800 ends at block 826. If there is an existing enabledPerpetualKey, the PerpetualKey is set such that PerpetualKey=pendingdisabled at block 828 prior to the ending of the method 800 at block826.

A number of additional APIs may also be included within the licensingsystem. For example, an UpdateEntitlementStatus( )API may be used toupdate the status of an entitlement. An UpdateBillingCountry( ) API maybe used to update the billing information of the user, i.e.,BillingCountryISO, and a GetDownloadInfo( )API may be used to return thedownload URL and other information relating to the entitlement.

In various embodiments, a secure token, i.e., SecureToken, is simply aglobally unique identifier (GUID) generated by the OLS that grantstemporary access to the entitlement as a user. When a client makes OLScalls with the SecureToken, the client is essentially calling OLS withthe credentials of the user for which the token was issued. The maindifferences between providing an identity ticket and providing a securetoken are that the secure token is scoped to a specific entitlement, soit can only be used to retrieve information or get a key for a specificentitlement, and the secure token is limited use and time bound.

A CheckMachineStatus( ) API returns the status of a machine. However,this API may only return information for machines that were provisionedunder subscription entitlements. A GetEntitlementsForIdentity( ) API mayreturn the entitlement(s) currently associated with the suppliedidentity. A GetEntitlementForMachineKey( ) API may return theentitlement currently associated with the MachineKey. In someembodiments, the process flow may be as follows: (1) RetrieveEntitlementID of the machine with matching MachineKey; (2) Retrieve theentitlement with the above EntitlementID, and (3) Return information onthe entitlement.

In addition, the GetKey( ) API may be the API from which the OLC canretrieve keyless authorizations and/or product keys for activation. Thelogic for this API can be broken down into multiple parts.

FIG. 9 is a process flow diagram of a method 900 for verifying anidentity of a user and an identity of an entitlement for which keylessauthorization is to be provisioned. The method 900 begins at block 902,at which the GetKey( ) API is called. At block 904, it is determined ifa SecuredToken was used. If a SecuredToken was used, the OLS token isvalidated at block 906. At block 908, it is determined whether the tokenis invalid. If the token is invalid, an error is returned at block 910.Is the token is valid, the TokenUseCount is determined at block 912. Theuser that is associated with the token is then retrieved at block 914.The method then proceeds to block 916.

In addition, if it is determined that a SecuredToken was not used atblock 904, the method 900 proceeds to block 918, at which the identityticket is validated. The method then continues at block 916, at which itis determined whether the user is on hold. If the user is on hold, anerror is returned at block 920. Otherwise, it is determined whether theEntitlementID exists at block 922. If the EntitlementID does not exist,an error is returned at block 924. Otherwise, it is determined whetherthe entitlement is suspended or deprovisioned at block 926. If theentitlement has been suspended or deprovisioned, an error is returned atblock 928. Otherwise, the method 900 continues to the keylessauthorization flow discussed below with respect to FIG. 10.

FIG. 10 is a process flow diagram of a method 1000 for provisioning akeyless authorization as appropriate. The purpose of the keylessauthorization may be to enable the client to run Office temporarilywithout OSPP and without activation using a product key. This may beuseful during a first run of an installation or during roamingapplication scenarios, for example.

The keyless authorization may be a signed string that includes anauthorization string that is used by the client to enable temporaryOffice access and is stored in the Offer as BaseAuthString. The keylessauthorization may also include a number of parameters, including a HWIDparameter that is sent by the client on the GetKey( ) request, and aTimeValidEnd parameter that represents the date and time at which theclient may no longer use the keyless authorization.

The keyless authorization flow of the method 1000 begins at block 1002.In various embodiments, the method 1000 is executed after the method900, as discussed above. The method 1000 may include making a number ofdeterminations at blocks 1004-1022, including determinations regardingthe type of key that was requested by the client, for example. If theconditions of the method 1000 are not met at blocks 1012 or 1014, anerror may be returned at blocks 1024 or 1026.

If conditions presented in the method 1000 have been met, it may bedetermined at block 1028 whether a product key was requested. If aproduct key was not requested, a keyless authorization is returned atblock 1030. If a product key was requested, it may be determined whetherthe entitlement offer allows installs, i.e., is not roaming only, atblock 1032. If the entitlement offer does not allow installs, an erroris returned at block 1034. Otherwise, it is determined whether the offertype is KeyOnly at block 1036.

If the offer type is not KeyOnly, the method 1000 proceeds to thesubscription key flow of FIG. 11A or 11B, as shown at block 1038. If theoffer type is KeyOnly, the method 1000 proceeds to the product key flowof FIG. 12A or 12B, as shown at block 1040.

FIG. 11A is a process flow diagram of a method 11000 for retrieving anexisting subscription (or TBL) key. In various embodiments, an existingkey is retrieved if the MachineKey and HWID used in the GetKey( ) APIcall are identical to those stored in the OLS. The subscription key flowof the method 1100 begins at block 1102. In various embodiments, themethod 1100 is executed after the method 1000, as discussed above. Themethod 1100 may include making a number of determinations and executinga number of steps at blocks 1104-1140. In some embodiments, the method1100 proceeds to the new subscription key flow of FIG. 11B, as shown atblock 1142. In other embodiments, an existing subscription key isreturned at the end of the method 1100, as shown at block 1144.

FIG. 11B is a process flow diagram of a method 1146 for obtaining a newsubscription key. In various embodiments, a new key is retrieved fromthe key store if a new install has occurred, a machine has run out oftolerance reactivations, an entitlement conversion has taken place, or amachine has been reprovisioned. The method 1146 may be executed afterthe method 1000 or the method 1100, as discussed above.

The new subscription key flow of the method 1146 begins at block 1148.After performing a number of steps at blocks 1150-1156, a newsubscription key is returned at block 1158. Alternatively, if acondition of the method 1146 is not met at block 1150, an error isreturned at block 1160, and a new subscription key is not obtained.

FIG. 12A is a process flow diagram of a method 1200 for retrieving anexisting product key. The method 1200 may apply to Key Only offer types.In various embodiments, the method 1200 is executed after the method1000, as discussed above. The product key flow of the method 1200 beginsat block 1202. The method 1200 may include making a number ofdeterminations and executing a number of steps at blocks 1204-1212. Insome embodiments, if a condition of the method 1200 is not met at block1206, an error is returned at block 1214. In other embodiments, themethod 1200 proceeds to the new product key flow of FIG. 12B, as shownat block 1216. Further, in other embodiments, an existing product key isreturned at the end of the method 1200, as shown at block 1216.

FIG. 12B is a process flow diagram of a method 1218 for obtaining a newproduct key. A new product key may only be obtained if an entitlement isnew or has been converted from a previous entitlement. The method 1218may be executed after the method 1000 or the method 1200, as discussedabove. The new product key flow of the method 1218 begins at block 1220.The method 1218 may include making a number of determinations andexecuting a number of steps at blocks 1222-1226. A new product key isthen returned at the end of the method 1218, as shown at block 1228.

FIG. 13 is a process flow diagram of a method 1300 for retrievingmachines from an entitlement. The method 1300 may be executed using aGetMachineList( ) API. The GetMachineList( ) API may return machines forwhich the user has requested keys. Callers may request machinesassociated with a specific entitlement, or machines having a specificstatus.

The method 1300 may begin at block 1302, at which the GetMachineList( )API is called. The method 1300 may include making a number ofdeterminations and executing a number of steps at blocks 1304-1316. Themachines from the entitlement(s) are then retrieved at block 1318, andthe list of machines is returned at block 1320.

In various embodiments, if the API is requested to attempt toGetMachineList( ) from an entitlement which is currently on a perpetualoffer, the API will still attempt to retrieve machines from thatentitlement because it is possible that the entitlement was convertedfrom a subscription offer and does have machines that are currentlyusing subscription keys.

FIG. 14 is a process flow diagram of a method 1400 for deprovisioning aspecific machine from an entitlement. The method 1400 may be executedusing a RemoveMachine( ) API. The RemoveMachine( ) API may be used tomark machines for deprovisioning. The deprovisioning may then beperformed asynchronously.

The method 1400 may begin at block 1402, at which the RemoveMachineList() API is called. The method 1400 may include making a number ofdeterminations and executing a number of steps at blocks 1404-1418. Insome embodiments, if one of the conditions of the method 1400 is not metat blocks 1408, 1416, or 1418, an error may be returned at block 1420,1422, or 1424, respectively. Otherwise, the machine status is set todeprovisioned at block 1426. This effectively removes the machine fromthe entitlement.

In various embodiments, the GetUrlForEntitlement( ) API returns thedownload URL to download the bits for an entitlement. This API functionssimilarly to the provisioning GetDownloadInfo( ) API. However, theidentity that is used may be tickets issued by BPOS or Live, or an OLSSecureToken, rather than a PUID. The SecureToken may not be regeneratedif the identity used is an OLS SecureToken. Rather, the existing tokenmay be used in the URL. This API also only returns the URL, not thedownload parameters.

According to embodiments described herein, the product key cache is akey store from which the OLS obtains keys. The product key cache is adatabase that is independent of the OLS core licensing database, and ispopulated by an asynchronous process which retrieves keys from a JITsystem whenever the number of available keys in the cache falls below acertain threshold.

The product key cache may store metadata on each key, including the PKPNof the key; the JIT SKU of the PKPN, and the datacenter country fromwhich the key was originally obtained. The product key cache may be ableto return a tax compliant key based on several parameters supplied bythe GetKey( ) logic, including entitlement KeyStoreReqId, which is anOffer attribute, and BillingCountryISO, which is obtained from theentitlement.

Within the OLS, the product key deprovisioning component may be anasynchronous service that runs independently of the core system. Theproduct key deprovisioning component may run on a regular schedule thatis initially set to once per day.

During the product key deprovisioning component's scheduled run, it mayidentify machines with key statuses, i.e., KeyStatus, that are pendingdisable and dates of last key status update, i.e., KeyStatusLastUpdate,of greater than two months. In addition, during the product keydeprovisioning component's scheduled run, it may identify product keyswith key statuses that are pending disable and dates of last key statusupdate of greater than one month. In some embodiments, a machine can bedeprovisioned due to a sync provider update or a user action, such as inresponse to a user removing the machine from the entitlement.

Office Marketplace Experience Sync Provider

The OMEX sync provider may be used to receive provisioning updates fromthe OMEX partner and to publish those updates into the OLS. Morespecifically, the OMEX sync provider is an abstraction layer thatexposes a set of APIs for the OMEX partner to perform variousprovisioning tasks without allowing the OMEX partner direct access tothe private provisioning layer in the OLS.

FIG. 15A is a process flow diagram of a method 1500 for the initialpurchase of an entitlement by a user. The method 1500 may be executedusing the OMEX sync provider discussed above. The user initiates thepurchase at block 1502, and the user selects the SKU through OMEX,either via the client or via the Web, at block 1504. At block 1506, theuser signs in using his Live ID, and the user completes the paymentinformation for purchasing the entitlement at block 1508.

OMEX calls CTP to complete the purchase action at block 1510, and callsthe OMEX sync provider to provision the user, i.e., ProvisionUser( ), atblock 1512. At block 1514, the OMEX sync provider provisions the userand returns the download URL. Provisioning the user in OLS may beaccomplished using the ProvisionUser( ) API. The ProvisionUser( ) APImay only be called by the OMEX partner.

In some cases, there is a timeout on the call to the sync provider.Therefore, at block 1516, it may be determined whether an error ortimeout has occurred. If an error or timeout has occurred, a “come backlater to download” message may be displayed to the user at block 1518.Otherwise, OMEX displays the download link for the entitlement to theuser at block 1520.

FIG. 15B is a process flow diagram of a method 1522 for updating anentitlement. The method 1522 begins at block 1524, at which the CTPstarts the provisioning callback. At block 1526, the OMEX licensingnotifier calls the OMEX sync provider to provision the user using theProvisionUser( ) API. At block 1528, the OMEX sync provider provisionsthe user or updates the entitlement. It is then determined whether anerror or timeout has occurred at block 1530. If an error or timeout hasoccurred, the method 1522 returns to block 1524. Otherwise, the method1522 ends at block 1532.

FIG. 16 is a process flow diagram of a method 1600 for provisioning auser in OLS, or converting a user from one entitlement to another. Themethod begins at block 1602, at which the ProvisionUser( ) API iscalled. It is determined whether a conversion flag was set a block 1604.

If a conversion flag was set, it may be determined whether theentitlement has been deprovisioned at block 1606. If the entitlement hasbeen deprovisioned, an exception is thrown at block 1608. Otherwise, theuser is converted to another entitlement at block 1610. Alternatively,if a conversion flag was not set at block 1604, the user is provisionedat block 1610.

A DownloadType is then requested at block 1612, and a download URL isreturned at block 1614. The returned download URL may include a securedtoken, e.g., a GUID, that allows a user to activate Office withoutretyping his credentials. Therefore, the use of the URL may be limited.In some embodiments, a GetDownloadInfoForEntitlement( ) API is used toregenerate the download link as appropriate.

FIG. 17 is a process flow diagram of a method 1700 for determiningwhether to update an entitlement according to a ForcedUpdate process.The method 1700 may begin at block 1702, at which the ProvisionUser( )API is called. The method 1700 may include making a number ofdeterminations and executing a number of steps at blocks 1704-1726. Insome embodiments, it is determined that the entitlement does not existat block 1718, and an exception is thrown at block 1728. Otherwise, themethod 1700 continues to block 1730, at which a download URL isreturned. The download URL may vary depending on whether a ForcedUpdatehas been set, as determined at block 1712 or block 1722, and whether anentitlement update is allowed, as determined at block 1724.

According to the method 1700, ForcedUpdate may be specified during theasynchronous CTP provisioning call because it may be the ultimateauthority on what the user has bought. A discrepancy may occur in raceconditions wherein the asynchronous CTP provisioning call occurs beforethe provisioning call initiated during purchase. In some cases, ifForcedUpdate is specified during provisioning, another update to thesame EntitlementID may not be allowed for 10 seconds from the lastsuccessful update unless ForcedUpdate is set on the new ProvisionUser( )API call. In this case, the call will succeed and will returninformation based on existing entitlement information. The time valuemay be configurable, and the logic for this check may be isolated in thesync provider layer.

For cases in which an update to the user's entitlement is not made, butthe call returns successfully, the response may contain a flag thatindicates to the caller that the update was not made. The response mayalso contain the entitlement information that is already in the system.The caller may use the entitlement information for troubleshooting or totake other additional actions.

Licensing for Devices

According to embodiments described herein, the OLS may be updated inorder to support licensing of different types of devices and specificapplications relating to the different types of devices. For example,the OLS may support licensing of Office, e.g., Office 2015, in the formof MOX applications, Mobile Office applications, Android applications,Windows Mobile applications, and Mac Office applications, among others.Therefore, the OLS may allow for licensing of Office across manydifferent platforms.

Within the OLS, the term “computers” may refer to PCs and Macs, and theterm “devices” may refer to MOX (or Slates) and mobile phones.Collectively, computers and devices may both be referred to as“machines” within the OLS.

Licenses for devices within the OLS may be in the form of eithercredential based licenses or token based licenses. For credential basedlicenses, any devices may share one license count, while any computersmay share another license count. For token based licensing, a licensetoken is used instead of an OLS token. License tokens can be used anunlimited number of times per device. There will be no device countbeyond limiting each license token such that it may only be used on onedevice.

Device applications, e.g., MOX and Mobile applications, may bedistributed through the platform's application store, e.g., Apple store,via OEM-preinstall, e.g., Windows Mobile, or via website download, e.g.,Android. Licensing rights for each device can be obtained via theplatform's application store with no OLS involvement, the OLS with thepurchase of a managed or an unmanaged subscription, or the OLS with a VLagreement.

FIG. 18A is a process flow diagram of a method 1800 for the initiallicensing of an application for a device. The method 180 begins at block1802, at which the user downloads the application from the device'sapplication store. At block 1804, the user is prompted for hiscredentials. At block 1806, the user signs in using his Live ID or othercredentials. The device then quires the OLS for license information atblock 1808, and the OLS returns an authorization string at block 1810.The device verifies the authenticity of the authorization string, savesthe machine key, and grants access at block 1812.

It is determined whether the device is authorized at block 1814. If thedevice is not authorized, an error is returned at block 1816. If thedevice is authorized, access to the application is granted at block 1818until a periodic check or reinstallation of the application.

FIG. 18B is a process flow diagram of a method 1820 for periodicallychecking the state of a license. In various embodiments, the method 1820is performed in response to an application's first boot of the day.

The method 1820 begins at block 1822, at which a device queries the OLSfor license information. The device may query the OLS on a devicedetermined interval, such as every fifth log-in or every month. At block1824, the device sends the machine key to the OLS.

At block 1826, the OLS returns the device state to the device. Access tothe application is granted if the device state is provisioned, as shownat block 1828. The authorization string is re-obtained from the OLS ifthe device state is pending conversion or converted, as shown at block1830. An error is returned if the device state is deprovisioned, asshown at block 1832.

FIG. 19 is a process flow diagram of a method 1900 for initiallylicensing a device. Like numbered items are as described with respect toFIG. 18A. The method 1900 may be performed in response to the first bootof a particular application on the device.

The method 1900 may be similar to the method 1800 of FIG. 18A. However,the user is prompted for a device token at block 1902, and the userprovides a device token at block 1904, instead of signing in with hisLive ID or other credentials. Therefore, according to the method 1900,the license for the device is a token based license. For token basedlicensing, the device is perpetually licensed to use the applicationonce the license has been initialized. Therefore, there may not be aperiodic license check for the license. Accordingly, at block 1906, thedevice is granted access to the application perpetually, or untilreinstallation of the application.

According to embodiments described herein, an OLS License is a new typeof license that may be granted by the OLS. The OLS license may be issuedby the GetOLSLicense( ) API. The OLS license may include a licensestring, i.e., MachineKey, a machine identification, i.e., MachineID, avalid date and time at which the authorization may begin to be used,i.e., TimeValidStart, and a valid date and time at which theauthorization may no longer be used, i.e., TimeValidEnd.

A device may only honor an OLS license returned by the GetOLSLicense( )API if the OLS license satisfies several criteria. For example, the OLSlicense may be verified to be signed by the OLS; the returned MachineIDmay be verified to match the MachineID used on the request; theTimeValidStart may be verified to match the current time used on therequest; and the current client time may be verified to be betweenTimeValidStart and TimeValidEnd.

Licensing for Services

Embodiments described herein may be used to perform various functionsrelating to licensing for services. For example, embodiments describedherein may allow a partner to identify whether a user is to be givenaccess to its roaming setting service. In addition, such embodiments mayprovide Office services an interface by which to retrieve Office clientprovisioning information.

FIG. 20 is a process flow diagram of a method 2000 for the determinationby a partner of whether a user is to be granted access to its services.Such a determination may be made using service provisioning information.In some embodiments, partners maintain a user provisioning cache thatcaches results from a GetEntitlementForIdentityEx( ) API call. This mayenhance performance of the partner and reduce the load on the OLS. Thelength of the user provisioning cache may be adjusted according to thecharacteristics of the particular service. In addition, the userprovisioning cache may expire based on how often real time informationis desired by the service and the performance cost of calling the OLSfor the provisioning information.

The method begins at block 2002, at which it is determined whether theuser provisioning cache exists and is valid. If the user provisioningcache exists and is valid, access to the service is granted at block2004. If the user provisioning cache either does not exist or is notvalid, the provider calls the GetEntitlementForIdentityEx( ) API atblock 2006. At block 2008, the partner updates the user provisioningcache. It is then determined whether the user is provisioned for theservice at block 2010. If the user is not provisioned for the service,access to the service is not granted, as shown at block 2012. Otherwise,the user is granted access to the service at block 2004.

Geolocation and Geoscaling Services

In various embodiments, geolocation and geoscaling techniques are usedto improve or maintain the performance, availability, reliability, andscalability of the OLS. The overall geolocation design for OLS mayinclude a master datacenter and numerous replica datacenters, which maybe geographically distributed around the world. This design maytheoretically support an unlimited number of replica datacenters. Eachreplica datacenter may be brought online as appropriate.

The master datacenter may handle all OLS operations. For example, writeoperations, e.g., provisioning updates, may pass through the masterdatacenter first. The master datacenter may contain a master copy ofprovisioning information for every user. In addition, all sync providercomponents and key cache components may reside within the masterdatacenter. Further, a geo-syncer may be used to continuously monitorthe master datacenter in order to determine updates that are to besynced to the replica datacenters.

Replica datacenters may handle all read operations, e.g., checking if auser has permission to access a service. Replica datacenters may alsohandle some write operations, e.g., issuing keyless authorizations. Eachreplica datacenter may contain a copy of the provisioning informationfor each user, and may obtain provisioning updates continuously from themaster datacenter. Further, in the case of disaster recovery scenarios,any of the replica datacenters may become the master datacenter, asdiscussed further below.

FIG. 21 is a schematic of an exemplary configuration of a masterdatacenter 2100 and multiple replica datacenters 2102A and 2102B. OMEX2104 or other partners may be given a generic OLS URL, e.g.,generic.ols.office.com, as well as a direct URL, e.g.,master.ols.office.com, for the master datacenter 2100. For certainoperations, such as operations of an OMEX sync provider 2106, OMEX 2104may call the master.ols.office.com directly rather than usinggeneric.ols.office.com. The calls may then be redirected from the masterdatacenter 2100 to either of the replica datacenters 2102A or 2102Bbased on logic within a global load balancer 2108.

In addition, a number of geo-syncers 2110A and 2110B may be used to syncinformation from the master datacenter 2100 into the replica datacenters2102A and 2102B. Specifically, each geo-syncer may read data from ageo-sync table within the master datacenter 2100 and write the data intothe replica datacenters 2102A and 2102B directly. Such data may includedata relating to provisioning updates or product key informationupdates, for example.

The geo-sync table within the master datacenter 2100 may containpointers to records in the OLS Core that may be synced into the replicadatacenters 2102A or 2102B. Specifically, the geo-sync table may containSourceTable Name, SourcePartition Key, SourceRow Key, ModifiedDateTime,and PublishPending pointers. Each time a write occurs in the OLS coretable, except for writes that impact only attributes in the exceptionlist, a record is created in the geo-sync table.

While only two geo-syncers 2110A and 2110B are shown in FIG. 21, theconfiguration may include a pool of geo-syncers 2110. As each geo-syncer2110 wakes up, it attempts to obtain a lock to sync out to a replicadatacenter 2102A or 2102B. Any geo-syncer 2110 may sync to any replicadatacenter 2102A or 2102B. However, only one geo-syncer 2110 may beactive per replica datacenter 2102A or 2102B at one time. Eachgeo-syncer 2110 will attempt to finish syncing against a single replicadatacenter 2102A or 2102B before attempting to obtain a lock to sync tothe next replica datacenter 2102A or 2102B. Further, all geo-syncers2110 may be run within the master datacenter 2100. In variousembodiments, the master datacenter 2100 contains a lock configurationfile that lists all replica datacenters 2102A and 2102B, thecorresponding locks, the corresponding lock durations, the correspondingPublishPending fields in the geo-sync table, and a switch to turn actualsyncing on or off. In addition, in some embodiments, a centralized synccontroller (not shown) may be used to manage the functioning of thegeo-syncers 2110.

Any number of new replica datacenters may be brought online at any pointin time. When a new replica datacenter is brought online, aconfiguration entry for the new replica datacenter may be added to thelock configuration file within the master datacenter 2100. Initially,the configuration entry may mark the new replica datacenter as “off” toensure that changes will start to be tracked for the replica datacenter.The current time may be noted, and all data within the master datacenter2100 up to the current time may be replicated into the new replicadatacenter. The configuration entry may then mark the new replicadatacenter as “on.” The geo-syncing procedure may then functionnormally.

Disaster Recovery

According to embodiments described herein, the use of the multipledatacenters, e.g., one master datacenter and at least two replicadatacenters, within the licensing system allows for disaster recovery inthe case of the failure of a datacenter. For example, a new datacentercan be brought online at any point in time as a replacement datacenterfor a datacenter that has failed. A replica datacenter may also bepromoted to the master datacenter if the previous master datacenter hasfailed. In addition, planned downtimes may be implemented at any pointin time.

The disaster recovery procedure may be used to recover OLS data. Becausethe OLS replicates data from the master datacenter to the replicadatacenters, there is already some built in redundancy within thelicensing system. However, due to geo-sync delays, data within eachreplica datacenter will likely not be at 100% parity with the masterdatacenter or with other replica datacenters at any point in time.Therefore, some data may be lost in the event of a disaster. Inaddition, the OLS may include provisioning data such as entitlementprovisioning data, OMEX provisioning data, and BPOS provisioning data.While some provisioning data may be recoverable from OLS provisioningpartners in the event of a disaster, some amount of provisioning datamay be lost. Therefore, it may be desirable to recover such data.

Planned Downtime

FIG. 22 is a schematic showing a first step for executing a planneddowntime. The first step may include stopping servicing calls from amaster datacenter 2200 and bringing replica datacenters 2202 and 2204 toparity, as described further below.

In some cases, the master datacenter 2200 within the OLS may bepurposefully taken down. For example, the master datacenter 2200 mayhave a faulty configuration that is to be corrected, or there may be amajor service update available for the master datacenter 2200 that canonly be implemented when the master datacenter 2200 is down.

When the master datacenter 2200 is to be taken down, a main replicadatacenter 2202 is brought online as the new master datacenter. The mainreplica datacenter 2202 may be a replica datacenter that is locatedclose to the master datacenter 2200 and is the first replica datacenterto be promoted to a new master datacenter if the master datacenter 2200is taken down.

In some embodiments, each datacenter is assigned a number, startingfrom 1. For example, the master datacenter 2200 may be assigned a numberof 1, the main replica datacenter 2202 may be assigned a number of 2,and the other replica datacenter 2204 may be assigned a number of 3.Each datacenter 2200, 2202, and 2204 may be self-aware of its assignednumber, as well as the maximum number. This numbering system may beuseful for making certain determinations during disaster scenarios. Forexample, if the master datacenter 2200 fails, the main replicadatacenter 2204 may be automatically promoted to the new masterdatacenter, since its number is 2. If the main replica datacenter 2204is not available, the replica datacenter 2204 may then be promoted tothe new master datacenter, since its number is 3.

As discussed above, the first step in executing a planned downtime maybe stopping servicing calls from the master datacenter 2200 and bringingthe main replica datacenter 2202 to parity. This may be accomplished byremoving the master datacenter 2200 from the generic OLS URL 2206, i.e.,generic.ols.office.com, rotation. The syncer component of a BPOS syncprovider 2208 of a BPOS partner 2210 may be stopped, and the publishcomponent may continue until there is nothing left to publish. All callsto a master OLS URL 2212, i.e., master.ols.office.com, may return aTemporarilyUnavailable exception. This includes calls to an OMEX SyncProvider 2214 of an OMEX partner 2216, the OLS API, and the OLS PartnerAPIs. In addition, geo-syncers 2218 may continue the geo-syncing processuntil there is nothing else left to sync. At the end of this process,all replica datacenters 2202 and 2204 will have synced all syncable datafrom master datacenter 2200 and, for all intents and purposes, will beat parity with the master datacenter 2200.

FIG. 23 is a schematic showing a second step for executing a planneddowntime. Like numbered items are as described with respect to FIG. 22.The second step may involve promoting the main replica datacenter 2202to the new master datacenter, as described further below.

During this step of the planned downtime, the database of the BPOSpartner 2210 may be copied from the old master datacenter, i.e., thedatacenter 2200, to the new master datacenter 2202. The lockconfiguration files may be updated. All components of the OMEX syncprovider 2214 and the BPOS sync provider 2208 may be turned on in thenew master datacenter 2204. All OLS API and OLS partner API calls may beturned on in the new master datacenter 2202. The master OLS USL 2212 maybe mapped to the new master datacenter 2202. In addition, the replicadatacenter 2204 may be designated as the new main replica datacenter,and the geo-syncing process may be turned on.

At the end of this step, the old main replica datacenter has beenpromoted to the new master datacenter 2202. Thus, the old masterdatacenter 2200 can now be taken down for maintenance, upgrades, or thelike. These steps may be reversed to convert the old master datacenter2200 back to the current master datacenter.

In some embodiments, it may be desirable to bring new replicadatacenters online. A new replica datacenter may be deployed by adding arecord for the replica datacenter to the lock configuration file ofevery datacenter with the syncing set to “off.” If a record is added,the replica datacenter is indeed a new replica datacenter. Otherwise, itis an existing replica datacenter, and the following steps do not apply.Once a record is added to the lock configuration file, the masterdatacenter may start collecting changes to be synced to the new replicadatacenter. Data may be copied from the master datacenter to the newreplica datacenter. After copying is complete, the new replicadatacenter may turn geo-syncing for itself on in the master datacenter'slock configuration file. In addition, the maximum number of datacentersmay be updated in every datacenter. Furthermore, the new replicadatacenter may be added to the global load balanced URL.

Unplanned Downtime

Unplanned downtime could occur due to various reasons. Any unplanneddowntime of a replica datacenter, e.g., either intermittent orpersistent downtime, can be handled agilely with modification of theglobal load balancer to redirect to another replica datacenter. Themaximum downtime may depend on the TTL time of the DNS entry of theglobal load balancer. However, unplanned downtime of a master datacenteris less agilely handled. Because the master datacenter is the onlydatacenter that performs provisioning and services certain API calls,traffic cannot simply be redirected to a backup datacenter.

If the master datacenter unexpectedly becomes unavailable for anextended period of time, the main replica datacenter can be promoted tothe new master datacenter. This may be accomplished by updating the lockconfiguration file, turning on the BPOS sync provider in the mainreplica datacenter, and turning on the OMEX sync provider in the mainreplica datacenter. In addition, all OLS API and OLS Partner API callsmay be turned on in the main replica datacenter, the master OLS URL maybe mapped to the main replica datacenter, another replica datacenter maybe designated as the main replica datacenter, and the geo-syncingprocess may be turned on. If a new master datacenter has beendesignated, and the old master datacenter unexpectedly comes backonline, data inconsistencies may be created as the old master datacentergeo-syncs old information into the replica datacenters. Therefore, stepsmay be taken to ensure that the old master datacenter cannot come backonline automatically. For example, a configuration deployment may beused to turn off the old master datacenter.

General Method and System for Application Licensing

FIG. 24 is a process flow diagram of a method 2400 for applicationlicensing. In various embodiments, the method 2400 is executed by thelicensing service, e.g., the OLS, within the licensing system describedherein. The method 2400 begins at block 2402, at which a license for anapplication is returned from a licensing service to a computing device.The license may be returned in response to receiving a call requestingthe license from the computing device, wherein the license is based onthe computing device or a user of the computing device, or anycombination thereof. In various embodiments, the license is based onmultiple computing devices, wherein the number of computing devices thatmay be used for the license is specified by the conditions of thelicense. The application may be a service, program, or application,which may be provided by a marketplace service or a third party service.Further, the license may be a license for multiple applications ormultiple services. In addition, the license may be a subscriptionlicense or a perpetual license.

At block 2404, the licensing service monitors a state of the license.Monitoring the state of the license may include detecting a fraudulentactivity, wherein a fraudulent activity is an activity that is notauthorized by the conditions of the license. In various embodiments,monitoring the state of the license includes determining if the licenseis expired. The state of the license may be synchronized across multiplecomputing devices that are used by the user.

At block 2406, the conditions of the license are adjusted according tothe state of the license. In some embodiments, adjusting the conditionsof the license includes deprovisioning the license if the license isexpired. Adjusting the conditions of the license may also includereprovisioning the license if the license is renewed by the user.

In some embodiments, the user may be allowed to use the applicationwithout remaining connected to the licensing service. However, the usermay be requested to connect the computing device to the licensingservice periodically in order to allow for the monitoring of the stateof the license. The license may be deprovisioned if the user does notconnect to the licensing service for a specified period of time.

It is to be understood that the process flow diagram of FIG. 24 is notintended to indicate that the steps of the method 2400 are to beexecuted in any particular order, or that all of the steps are to beincluded in every case. Further, any number of additional steps may beincluded within the method 2400, depending on the details of thespecific implementation.

Method for Licensing Services

A method for licensing services is disclosed herein. The method includesusing, within a licensing service, a poll model to license a service toa user or a computing device, or any combination thereof. In variousembodiments, another method for licensing services may also includeusing, within a licensing service, a push model to license a service toa user or a computing device.

Method for Providing Business Continuity

A method of providing business continuity including a pool of processeswhich continuously distribute data within a datacenter or acrossmultiple geographically disperse datacenters is also disclosed herein.Further, a system for providing business continuity, robustness, andredundancy is disclosed herein. The system includes a set of locks, aset of processes which obtain the locks, and a queue of changes tobusiness data or licensing data, or both. The system also includes amechanism to manage the changes and a mechanism to write the businessdata or the licensing data, or both, across datacenters.

Method for Application Licensing Mink Sync Providers

FIG. 25 is a process flow diagram of a method 2500 for licensing anapplication using sync providers. The application that is to be licensedmay be a word processing application, a spreadsheet application, or apresentation application, for example. In addition, the application maybe a service that is provided by a specific commerce partner.

The method begins at block 2502, at which a request for a license for anapplication is received from a client sync provider at a licensingservice. In some embodiments, the client sync provider corresponds to aspecified client computing device, and the license permits use of theapplication on the specified client computing device. Further, in someembodiments, the license permits use of the application on the clientcomputing device based on an input of client credentials.

At block 2504, information relating to the license is received from acommerce partner offering the application via a commerce partner syncprovider. In some embodiments, the licensing service includes a numberof provisioning APIs for communicating with the client sync provider andthe commerce partner sync provider.

At block 2506, the license for the application is returned to a clientcomputing device. At block 2508, information relating to the state ofthe license is received from the client sync provider. Informationrelating to the state of the license may also be received from thecommerce partner sync provider. In some embodiments, the state of thelicense is synchronized across a number of client computing devicescorresponding to the client sync provider. Further, in some embodiments,the state of the license is directly monitored via the licensingservice.

At block 2510, the conditions of the license are adjusted according tothe state of the license. For example, the license may be deprovisionedif the license has an expired state, or the license may be reprovisionedif the license has a renewed state. Further, the license may beconverted to a different license is the license has a converted state.

It is to be understood that the process flow diagram of FIG. 25 is notintended to indicate that the steps of the method 2500 are to beexecuted in any particular order, or that all of the steps are to beincluded in every case. Further, any number of additional steps may beincluded within the method 2500, depending on the details of thespecific implementation. For example, in some embodiments, the method2500 includes licensing an application using a system of pluggable syncproviders including one or more client sync providers and a number ofcommerce partner sync providers.

Method for Licensing an Application Using Multiple Forms of Licensing

FIG. 26 is a process flow diagram of a method 2600 for licensing anapplication using multiple forms of licensing. The method begins atblock 2602, at which a first form of a license is provided to a firstcomputing device via a licensing service. The first form of the licensemay be provided to the first computing device in response to an input bya user, such as an input of user credentials or a product key. At block2604, a second form of the license is provided to a second computingdevice via the licensing service. The second form of the license may beprovided to the second computing device in response to an input by auser, such as an input of user credentials or a product key. In variousembodiments, the first form of the license and the second form of thelicense include a product key based license, an online user basedlicense, a device based license, or a token based license, or anycombinations thereof.

A first state of the first form of the license and a second state of thesecond form of the license are determined at block 2606, and the firststate and the second state are synchronized to form a combined licensestate at block 2608. Further, at block 2610, the conditions of thelicense are adjusted based on the combined license state. In someembodiments, the combined license state includes an expired state, arenewed state, a converted license state, or an effective state, or anycombinations thereof. If the combined license state is an expired state,adjusting the conditions of the license may include deprovisioning thelicense. If the combined license state is a renewed state, adjusting theconditions of the license may include reprovisioning the license. If thecombined license state is an effective state, the conditions of thelicense may not be adjusted. If the combined license state is aconverted license state, the license may be converted to a differentlicense.

It is to be understood that the process flow diagram of FIG. 26 is notintended to indicate that the steps of the method 2600 are to beexecuted in any particular order, or that all of the steps are to beincluded in every case. Further, any number of additional steps may beincluded within the method 2600, depending on the details of thespecific implementation. For example, the method 2600 may includedetecting a fraudulent activity based on the combined license state,wherein the fraudulent activity includes an activity that is notauthorized by the conditions of the license. The conditions of thelicense may then be adjusted based on the detection of the fraudulentactivity.

Method for Licensing Applications for Devices

FIG. 27 is a process flow diagram of a method 2700 for licensing anapplication for devices. The method begins at block 2702, at which alicense for an application is provided from a licensing service to anumber of computing devices being used by a user. The license for theapplication may include credentials. The license may be provided to eachcomputing device in response to an input by a user.

At block 2704, the credentials are associated with each of the computingdevices. For example, an identification of each computing device may beassociated with the credentials. Once the credentials have beenassociated with a particular computing device, the user may be allowedto use the application on the computing device for a specified period oftime without connecting to the licensing service.

At block 2706, the state of a subscription corresponding to the licenseon each of the computing device is periodically determined. In variousembodiments, the state of the subscription on each computing device isdetermined at configurable time periods specified by the conditions ofthe license. The state of the subscription on a computing device may bedetermined in response to a check subscription state call received fromthe computing device. The check subscription state call may include anoutcome of a subscription state check performed by the computing device.The conditions of the license may then be adjusted based on the state ofthe subscription on each computing device. For example, the license maybe deprovisioned if the subscription is expired on a particularcomputing device, or the license may be reprovisioned if thesubscription is renewed on a particular computing device. In addition,the license may be converted to a different license if the subscriptionhas been converted on a particular computing device.

It is to be understood that the process flow diagram of FIG. 27 is notintended to indicate that the steps of the method 2700 are to beexecuted in any particular order, or that all of the steps are to beincluded in every case. Further, any number of additional steps may beincluded within the method 2700, depending on the details of thespecific implementation.

Method for Providing User Based Licenses for Applications

FIG. 28 is a process flow diagram of a method 2800 for providing userbased licensing of an application. The method begins at block 2802, atwhich user log-in information is received from a computing device at alicensing service in response to an input by a user. The user log-ininformation may be associated with the licensing service, or a commercepartner associated with the licensing service.

At block 2804, a license for an application is provided to the computingdevice, wherein the license includes device specific informationassociated with the user. The device specific information may includeinformation relating to the computing devices on which the user isprovisioned to use the application according to the license. Inaddition, the device specific information may include a total number ofcomputing devices on which the user is allowed to be provisioned to usethe application according to the license.

At block 2806, the application is activated on the computing deviceusing the input of the device specific information. The user may then beallowed to use the application on the computing device. In someembodiments, the user is allowed to use the application on the computingdevice for a specified period of time without connecting the computingdevice to the licensing service.

In some embodiments, the state of the license may be periodicallydetermined in response to an input from the computing device, whereinthe input includes an outcome of a license state check performed by thecomputing device. The state of the license may be checked atconfigurable time periods specified by the licensing service or thelicense itself. The conditions of the license may then be adjusted basedon the state of the license.

It is to be understood that the process flow diagram of FIG. 28 is notintended to indicate that the steps of the method 2800 are to beexecuted in any particular order, or that all of the steps are to beincluded in every case. Further, any number of additional steps may beincluded within the method 2800, depending on the details of thespecific implementation. For example, the license for the applicationmay be roamed across a number of computing devices that are used by theuser.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

1-20. (canceled)
 21. A method for managing application access,comprising: receiving, at a licensing service, license information for adeprovisioned license; indexing the license information for thedeprovisioned license in an index; receiving, at the licensing service,a license state check from a service partner; comparing the licensestate check to the index; and returning to the service partner theresults of the comparison, the results comprising information that adeprovisioned license corresponds to the license state check or that nocorresponding deprovisioned license was found.
 22. The method of claim21, wherein the licensing service returns a response to a license statecheck that is to indicate a valid license only for a number of times theapplication is used.
 23. The method of claim 21, wherein the licenseprovided to the computing device performs a license state checkasynchronously from a core system of the computing device.
 24. Themethod of claim 21, wherein the results of the comparison that arereturned to the service partner comprise information to allow additionaluse of an application after the comparison of the license state checkindicates a license for the application is deprovisioned.
 25. The methodof claim 21, comprising returning to the service partner an additionalresponse to a license state check that is to inform of impendingdeactivation, the time until impending deactivation, or any combinationthereof.
 26. The method of claim 21, wherein the returning to theservice partner the results of the comparison comprises an indicationthat an application from which a license state check was received maycontinue to operate as though the license was not deprovisioned duringtimes when the service partner is disconnected from the licensingservice.
 27. The method of claim 21, wherein the returning to theservice partner the results of the comparison include results that is tosynchronize with a connected device of the service partner if adeprovisioned license corresponding to the license state check is found.28. A system for managing application access, comprising: a servercommunicatively coupled to a computing device, the server comprising aprocessing device to carry out operations of a licensing serviceconfigured to: receive at the licensing service license information fora deprovisioned license; index the license information for thedeprovisioned license in an index; receive, at the licensing service, alicense state check from a service partner; compare the license statecheck to the index; and return to the service partner the results of thecomparison, the results comprising information that a deprovisionedlicense corresponds to the license state check or that no correspondingdeprovisioned license was found.
 29. The system of claim 28, wherein thelicensing service returns a response to a license state check that is toindicate a valid license only for a number of times the application isused.
 30. The system of claim 28, wherein the license provided to thecomputing device performs a license state check asynchronously from acore system of the computing device.
 31. The system of claim 28, whereinthe results of the comparison that are returned to the service partnercomprise information to allow additional use of an application after thecomparison of the license state check indicates a license for theapplication is deprovisioned.
 32. The system of claim 28, comprisingreturning to the service partner an additional response to a licensestate check that is to inform of impending deactivation, the time untilimpending deactivation, or any combination thereof.
 33. The system ofclaim 28, wherein the returning to the service partner the results ofthe comparison comprises an indication that an application from which alicense state check was received may continue to operate as though thelicense was not deprovisioned during times when the service partner isdisconnected from the licensing service.
 34. The system of claim 28,wherein the returning to the service partner the results of thecomparison include results to synchronize with a connected device of theservice partner if a deprovisioned license corresponding to the licensestate check is found.
 35. A computer-readable storage device comprisinga plurality of instructions that, when executed by a processor, causethe processor to: receive at the licensing service license informationfor a deprovisioned license; index the license information for thedeprovisioned license in an index; receive, at the licensing service, alicense state check from a service partner; compare the license statecheck to the index; and return to the service partner the results of thecomparison, the results comprising information that a deprovisionedlicense corresponds to the license state check or that no correspondingdeprovisioned license was found.
 36. The computer-readable storagedevice of claim 35, wherein the licensing service returns a response toa license state check that is to indicate a valid license only for anumber of times the application is used.
 37. The computer-readablestorage device of claim 35, wherein the results of the comparison thatare returned to the service partner comprise information to allowadditional use of an application after the comparison of the licensestate check indicates a license for the application is deprovisioned.38. The computer-readable storage device of claim 35, comprisingreturning to the service partner an additional response to a licensestate check is to inform of impending deactivation, the time untilimpending deactivation, or any combination thereof.
 39. Thecomputer-readable storage device of claim 35, wherein the returning tothe service partner the results of the comparison comprises anindication that an application from which a license state check wasreceived may continue to operate as though the license was notdeprovisioned during times when the service partner is disconnected fromthe licensing service.
 40. The computer-readable storage device of claim35, wherein the returning to the service partner the results of thecomparison include results to synchronize with a connected device of theservice partner if a deprovisioned license corresponding to the licensestate check is found.